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

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

mergesort code segfaulting on smallish arrays

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

Contents

  mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 10:39 -0500
    Re: mergesort code segfaulting on smallish arrays Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-07 07:48 -0800
      Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-07 16:02 +0000
      Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 11:34 -0500
        Re: mergesort code segfaulting on smallish arrays Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-07 08:41 -0800
          Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 13:02 -0500
            Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-07 10:37 -0800
              Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 14:38 -0500
                Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 16:44 +0100
                  Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 13:01 -0500
                    Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 10:39 +0100
                      Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 10:52 +0100
                      Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 11:12 +0100
            Re: mergesort code segfaulting on smallish arrays Barry Schwarz <schwarzb@delq.com> - 2019-11-07 12:28 -0800
            Re: mergesort code segfaulting on smallish arrays jadill33@gmail.com - 2019-11-07 13:13 -0800
              Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-08 00:55 +0000
                Re: mergesort code segfaulting on smallish arrays jadill33@gmail.com - 2019-11-08 05:30 -0800
          Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 14:50 +0100
            Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 09:31 -0500
              Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 09:39 -0500
            Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-08 17:53 +0000
              Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 13:15 -0500
                Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-08 20:01 +0000
                  Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 00:24 +0000
                    Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 09:44 -0500
                      Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 15:45 +0000
                        Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 14:30 -0500
                    Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 12:41 -0500
                      Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 19:29 +0000
                        Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 14:59 -0500
                          Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 22:00 +0000
                            Re: mergesort code segfaulting on smallish arrays Ian Collins <ian-news@hotmail.com> - 2019-11-10 11:24 +1300
                              Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 22:48 +0000
                                Re: mergesort code segfaulting on smallish arrays Ian Collins <ian-news@hotmail.com> - 2019-11-10 12:09 +1300
                                Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 14:46 +0100
                                  Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 14:11 +0000
                                    Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 17:27 +0100
                              Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-09 14:53 -0800
                                Re: mergesort code segfaulting on smallish arrays Ian Collins <ian-news@hotmail.com> - 2019-11-10 12:02 +1300
              Re: mergesort code segfaulting on smallish arrays Ian Collins <ian-news@hotmail.com> - 2019-11-09 09:25 +1300
              Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-09 20:18 +0000
                Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 21:55 -0500
                  Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-10 09:49 +0000
        Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-07 10:34 -0800
    Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-07 16:12 +0000
      Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 12:19 -0500
        Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-07 17:42 +0000
          Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 13:32 -0500
      Re: mergesort code segfaulting on smallish arrays Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-11-07 11:15 -0700
        Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-07 21:57 +0000
          Re: mergesort code segfaulting on smallish arrays Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-11-07 19:11 -0700
        Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-07 21:57 +0000
    Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 09:21 +0100
      Re: mergesort code segfaulting on smallish arrays chad <cdalten@gmail.com> - 2019-11-08 04:10 -0800
        Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 13:21 +0100
          Re: mergesort code segfaulting on smallish arrays chad <cdalten@gmail.com> - 2019-11-13 04:12 -0800
            Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 13:55 +0100
        Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 09:20 -0500
      Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 10:23 -0500
        Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 16:36 +0100
          Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 11:56 -0500
            Re: mergesort code segfaulting on smallish arrays Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-08 09:42 -0800
              Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 13:39 -0500
      Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 17:14 +0100
        Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 12:00 -0500
          Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:27 -0800
            Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-15 08:17 +0100
              Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-15 13:16 -0800
                Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-15 22:35 +0000
                  Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-16 13:34 -0800
                    Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-16 23:01 +0000
                      Re: mergesort code segfaulting on smallish arrays Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-17 08:34 +0000
                        Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-17 09:13 +0000
                          Re: mergesort code segfaulting on smallish arrays Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-17 09:30 +0000
                            Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-17 13:53 -0800
                          Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 10:27 +0100
                            Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-17 09:44 +0000
                              Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 10:50 +0100
                Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-16 07:26 +0100
        Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 18:07 +0100
          Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 12:40 -0500
            Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 20:41 +0100
              Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:28 -0800
      Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 06:14 +0100
        Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 08:03 +0100
        Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 02:20 -0500
          Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 08:21 +0100
      Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 08:30 +0100
        Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 12:50 -0500
          Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 19:18 +0100
            Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 14:27 -0500
              Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 07:46 +0100
                Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 09:32 +0100
                  Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-13 09:34 -0500
                    Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 16:01 +0100
                      Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 17:19 +0100
                      Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-13 16:32 +0000
                        Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 17:50 +0100
                          Re: mergesort code segfaulting on smallish arrays chad <cdalten@gmail.com> - 2019-11-13 11:09 -0800
                          Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-13 19:18 +0000
                            Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 20:31 +0100
                      Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 17:12 -0800
                      Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 20:26 -0800
                        Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 06:16 +0100
                          Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 06:40 +0100
                          Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-14 01:11 -0500
                            Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 10:41 +0100
                        Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 06:42 +0100
                          Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 21:56 -0800
                            Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 10:42 +0100
                      Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 06:39 +0100
                      Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 21:38 -0800
    Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 14:33 +0100
      Re: mergesort code segfaulting on smallish arrays Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-08 05:44 -0800
        Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 14:48 +0100
          Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 15:01 +0100
            Re: mergesort code segfaulting on smallish arrays Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-08 08:00 -0800
              Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 17:12 +0100
              Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-08 16:34 +0000
                Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-12 17:05 +0000
                Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 18:07 +0100
      Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-08 23:50 +0000
        Re: mergesort code segfaulting on smallish arrays Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 19:55 -0800
          Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 17:27 +0100
            Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-09 19:33 +0000
              Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-09 18:05 -0800
              Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 05:58 +0100
                Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 12:39 +0000
                  Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 12:48 +0000
                  Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 14:38 +0100
                    Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-10 13:42 +0000
                      Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 14:46 +0100
                        Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-10 14:04 +0000
                          Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:05 +0100
                            Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-10 14:09 +0000
                              Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:19 +0100
                    Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 14:06 +0000
                      Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:22 +0100
                        Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 14:30 +0000
                          Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 14:36 +0000
                            Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:59 +0100
                              Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 15:26 +0000
                          Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:56 +0100
                            Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 15:21 +0000
                              Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 16:28 +0100
                                Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 15:38 +0000
                                  Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 16:58 +0100
                                    Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 16:59 +0100
                                      Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 16:24 +0000
                                        Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 17:37 +0100
                                          Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-10 17:22 +0000
                                            Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 18:04 +0000
                                            Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 19:10 +0100
                                              Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 19:14 +0100
                                                Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-11 02:14 +0000
                                                  Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-10 22:07 -0500
                                                    Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-11 22:16 +0000
                                                  Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-11 06:52 +0100
                                                    Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-11 10:33 -0800
                                                    Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-11 23:28 +0000
                                                      Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 10:56 +0100
                                                        Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-12 02:35 -0800
                                                        Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-12 15:01 +0000
                                                          Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 16:08 +0100
                                                            Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-12 15:53 +0000
                                                              Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 16:56 +0100
                                              Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-11 13:45 +0100
                                                Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 08:00 -0800
                                                  Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 17:03 +0100
                                                    Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 08:27 -0800
                                                      Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 17:29 +0100
                                                Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 08:18 -0800
                                                  Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 17:27 +0100
                                                    Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 08:43 -0800
                                                      Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 18:01 +0100
                                                        Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 09:41 -0800
                                                          Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 18:44 +0100
                                                            Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 11:00 -0800
                                                              Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 20:03 +0100
                                                                Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 11:22 -0800
                                                                Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 20:24 +0100
                                                                  Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 11:44 -0800
                                                                    Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 06:23 +0100
                                                                      Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-13 06:40 -0800
                                                                        Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 16:34 +0100
                                                                          Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-13 08:41 -0800
                                Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-11 11:24 -0800
            Re: mergesort code segfaulting on smallish arrays Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-10 05:13 -0800
          Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-09 19:36 +0000
            Re: mergesort code segfaulting on smallish arrays Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-10 05:27 -0800
        Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 05:25 +0100
          Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 11:30 -0500
            Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 17:49 +0100
              Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 12:21 -0500
                Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 18:53 +0100
                  Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 13:33 -0500
                    Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 19:37 +0100
                      Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 18:51 +0000
                        Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 14:46 -0500
                        Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 15:35 +0100
                          Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 14:48 +0000
                      Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 15:35 +0100
                        Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:39 +0100
                          Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 19:54 +0100
                            Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 19:55 +0100
                              Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 21:34 +0100
                                Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 21:37 +0100
                      Re: mergesort code segfaulting on smallish arrays Robert Wessel <robertwessel2@yahoo.com> - 2019-11-11 11:12 -0600
                    Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 15:28 +0100
                      Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:41 +0100
                Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-09 12:47 -0800
                Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 15:08 +0100
                  Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-10 14:30 -0800
            Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-09 12:43 -0800
              Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 17:16 -0500
          Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-09 19:27 +0000
            Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 05:55 +0100
              Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-10 16:45 +0000
                Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 17:53 +0100
                  Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-11 00:56 +0000

Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11  Next page →

#147788

On 08/11/2019 13:50, Bonita Montero wrote:
>>> and that did it.
>> You also need to free the arrays, or you get a memory leak.
> 
>> You should also check for null, though on a modern system it is very
>> unlikely that malloc will refuse to give you a sane amount of memory.
> 
> DFS is light-years distant from writing production-quality code.
> I think he will never get there.

I wrote a merge-sort in my dynamic language based on DFS's C code. It 
worked first time.

Doing that from your C++ would have been impossible as I couldn't make 
head nor tail of it.

The speed of it (considering the code is unoptimised, and the 
interpreter is built unoptimised) isn't too bad either:

Time to sort 10 million random integers:

   Interpreted:     33.7 seconds     (here 64-bit not 32-bit ints)
   Your C++:         1.6 seconds     (using g++ -O3)
   Your C++:        15.6 seconds     (using g++ -O0)
   DFS C:            3.4 seconds     (using gcc -O3)
   DFS C:            6.5 seconds     (using gcc -O0)

That 15.6 seconds figure is interesting: without optimising (and 
presumably reducing a huge amount of boilerplate code), the native-code 
C++ is barely double the speed of interpreted byte-code! And here all 
the action happens in byte-code too, not in some library.

-------------------------------------------------------------------
BTW here is the script version of algorithm. Compare with your C++. This 
mergesort will also sort lists of strings or floats with no changes at all.
------------------------------------------------

proc start=
     N:=10 million
     a:=()

     to N do
         a append:=random(0)
     od

     mergesort(a)

     println =issorted(a)
end

proc mergesort(a, ?l, ?r) =
     if l.isvoid then (l,r):=a.bounds fi

     if l<r then
         m := l+(r-l)%2      # int divide
         mergesort(a, l, m)
         mergesort(a, m+1, r)
         merge(a, l, m, r)
     fi
end

proc merge(a, l, m, r) =

     b ::= a[l..m]            # deep copy
     c ::= a[m+1..r]

     i:=j:=1
     k:=0

     while i<=b.upb and j<=c.upb do
         if b[i] <= c[j] then
             a[l+k] := b[i]
             ++i
         else
             a[l+k] := c[j]
             ++j
         fi
         ++k
     od

     while i<=b.upb do a[l+k] := b[i]; ++k; ++i od
     while j<=c.upb do a[l+k] := c[j]; ++k; ++j od
end

function issorted(a)=
     for i:=a.lwb to a.upb-1 do
         if a[i]>a[i+1] then return 0 fi
     od

     return 1
end

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

#147791

On 11/8/2019 12:53 PM, Bart wrote:
> On 08/11/2019 13:50, Bonita Montero wrote:
>>>> and that did it.
>>> You also need to free the arrays, or you get a memory leak.
>>
>>> You should also check for null, though on a modern system it is very
>>> unlikely that malloc will refuse to give you a sane amount of memory.
>>
>> DFS is light-years distant from writing production-quality code.
>> I think he will never get there.
> 
> I wrote a merge-sort in my dynamic language 


Pretty freakin' cool that you wrote your own language!

Do you have a name for it?

Is it feature-complete, or still a work in progress?





> based on DFS's C code. It 
> worked first time.
> 
> Doing that from your C++ would have been impossible as I couldn't make 
> head nor tail of it.
> 
> The speed of it (considering the code is unoptimised, and the 
> interpreter is built unoptimised) isn't too bad either:
> 
> Time to sort 10 million random integers:
> 
>    Interpreted:     33.7 seconds     (here 64-bit not 32-bit ints)

About python speed, I would guess.


>    Your C++:         1.6 seconds     (using g++ -O3)
>    Your C++:        15.6 seconds     (using g++ -O0)
>    DFS C:            3.4 seconds     (using gcc -O3)
>    DFS C:            6.5 seconds     (using gcc -O0)
> 
> That 15.6 seconds figure is interesting: without optimising (and 
> presumably reducing a huge amount of boilerplate code), the native-code 
> C++ is barely double the speed of interpreted byte-code! And here all 
> the action happens in byte-code too, not in some library.
> 
> -------------------------------------------------------------------
> BTW here is the script version of algorithm. Compare with your C++. This 
> mergesort will also sort lists of strings or floats with no changes at all.
> ------------------------------------------------

This is your actual language?  I wrote a few SAS procs back in the day.


> proc start=
>      N:=10 million
>      a:=()
> 
>      to N do
>          a append:=random(0)
>      od
> 
>      mergesort(a)
> 
>      println =issorted(a)
> end
> 
> proc mergesort(a, ?l, ?r) =
>      if l.isvoid then (l,r):=a.bounds fi
> 
>      if l<r then
>          m := l+(r-l)%2      # int divide
>          mergesort(a, l, m)
>          mergesort(a, m+1, r)
>          merge(a, l, m, r)
>      fi
> end
> 
> proc merge(a, l, m, r) =
> 
>      b ::= a[l..m]            # deep copy
>      c ::= a[m+1..r]
> 
>      i:=j:=1
>      k:=0
> 
>      while i<=b.upb and j<=c.upb do
>          if b[i] <= c[j] then
>              a[l+k] := b[i]
>              ++i
>          else
>              a[l+k] := c[j]
>              ++j
>          fi
>          ++k
>      od
> 
>      while i<=b.upb do a[l+k] := b[i]; ++k; ++i od
>      while j<=c.upb do a[l+k] := c[j]; ++k; ++j od
> end
> 
> function issorted(a)=
>      for i:=a.lwb to a.upb-1 do
>          if a[i]>a[i+1] then return 0 fi
>      od
> 
>      return 1
> end

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

#147796

On 08/11/2019 18:15, DFS wrote:
> On 11/8/2019 12:53 PM, Bart wrote:


>> I wrote a merge-sort in my dynamic language 
> 
> 
> Pretty freakin' cool that you wrote your own language!

(Quite a few actually, but only two active at the minute (I started 
creating them in the early 80s). The dynamic one is what I wrote the 
sort program with; the other static one, in the same syntax, is used for 
systems programming, and writing compilers and the interpreter for the 
other.)

> Is it feature-complete, or still a work in progress?

(They're always a work in progress! But I no longer make them available 
via links as I sometimes did, as docs and support is too much work.)

>> Time to sort 10 million random integers:
>>
>>    Interpreted:     33.7 seconds     (here 64-bit not 32-bit ints)
> 
> About python speed, I would guess.

CPython 3.7 takes 310 seconds to sort the same data. PyPy might be 
faster, but I don't have a working version right now (but IMO it cheats 
anyway by JITing the code so that it is no longer interpreted byte-code; 
mine is lightly accelerated but still executing a byte-code at a time).

Anyway, here is the Python version (to run on 2.7, I guess you have to 
take out those underscores):

-------------------------------------------------------
import random

def fn():
     N=10_000_000
     a=[]
     for i in range(N):
         a.append(random.randint(0,999999999))

     mergesort(a,0,N-1)

     print ("Sorted:",issorted(a))

def issorted(a):
     for i in range(0,len(a)-2):
         if a[i] > a[i+1]: return 0
     return 1

def mergesort(a, l, r):
     if l<r:
         m = l+(r-l)//2         # // is int divide I hope
         mergesort(a, l, m)
         mergesort(a, m+1, r)
         merge(a, l, m, r)


def merge(a, l, m, r):
     b = a[l:m+1]               # slicing creates a copy
     c = a[m+1:r+1]

     i=0
     j=0
     k=0

     while i<len(b) and j<len(c):
         if b[i] <= c[j]:
             a[l+k] = b[i]
             i+=1
         else:
             a[l+k] = c[j]
             j+=1
         k+=1

     while i<len(b): a[l+k] = b[i]; k+=1; i+=1
     while j<len(c): a[l+k] = c[j]; k+=1; j+=1

fn()
-------------------------------------------------------

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

#147803

On 08/11/2019 20:01, Bart wrote:
> On 08/11/2019 18:15, DFS wrote:
>> On 11/8/2019 12:53 PM, Bart wrote:
> 
> 
>>> I wrote a merge-sort in my dynamic language 
>>
>>
>> Pretty freakin' cool that you wrote your own language!

>> Is it feature-complete, or still a work in progress?
> 
> (They're always a work in progress! But I no longer make them available 
> via links as I sometimes did, as docs and support is too much work.)

It's possible to try it out; download these two source files to the same 
place:

    https://raw.githubusercontent.com/sal55/qx/master/qq64.c (note 1.6MB)
    https://raw.githubusercontent.com/sal55/qx/master/merge.q

Compile the C file using one of these commands in a console (I assume 
you have 64-bit Windows):

    gcc -O3 qq64.c -oqq.exe
    tcc     qq64.c -oqq.exe -luser32

Then run that merge sort test:

    qq merge.q

This is a representation of the 'Q' interpreter in 100% C code, so 
doesn't include the acceleration I normally use that relies on inline 
ASM. On my machine I get these values for N=10 million (you can edit 
that inside merge.q especially to start to get a quicker test):

   gcc-O3       1   minute
   tcc          3   minutes
   (mine        1/2 minute using some inline ASM, otherwise no
                    code optimisations at all)

(Performance with 100% HLL can be improved, but I normally use the 
acceleration which is far more effective, so I haven't bothered.

I like making fairly elaborate programs accessible, via easy-to-compile 
single files, and the above is one example. No makefiles are needed!)

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

#147826

On 11/8/2019 7:24 PM, Bart wrote:
> On 08/11/2019 20:01, Bart wrote:
>> On 08/11/2019 18:15, DFS wrote:
>>> On 11/8/2019 12:53 PM, Bart wrote:
>>
>>
>>>> I wrote a merge-sort in my dynamic language 
>>>
>>>
>>> Pretty freakin' cool that you wrote your own language!
> 
>>> Is it feature-complete, or still a work in progress?
>>
>> (They're always a work in progress! But I no longer make them 
>> available via links as I sometimes did, as docs and support is too 
>> much work.)
> 
> It's possible to try it out; download these two source files to the same 
> place:
> 
>     https://raw.githubusercontent.com/sal55/qx/master/qq64.c (note 1.6MB)
>     https://raw.githubusercontent.com/sal55/qx/master/merge.q


I can never get that first one.  It takes forever to finish loading to 
screen, and then it won't allow copy-paste.  Using Opera fwiw.

Can you save it as a file for download?


> Compile the C file using one of these commands in a console (I assume 
> you have 64-bit Windows):
> 
>     gcc -O3 qq64.c -oqq.exe
>     tcc     qq64.c -oqq.exe -luser32
> 
> Then run that merge sort test:
> 
>     qq merge.q
> 
> This is a representation of the 'Q' interpreter in 100% C code, so 
> doesn't include the acceleration I normally use that relies on inline 
> ASM. On my machine I get these values for N=10 million (you can edit 
> that inside merge.q especially to start to get a quicker test):
> 
>    gcc-O3       1   minute
>    tcc          3   minutes
>    (mine        1/2 minute using some inline ASM, otherwise no
>                     code optimisations at all)
> 
> (Performance with 100% HLL can be improved, but I normally use the 
> acceleration which is far more effective, so I haven't bothered.
> 
> I like making fairly elaborate programs accessible, via easy-to-compile 
> single files, and the above is one example. No makefiles are needed!)

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

#147827

On 09/11/2019 14:44, DFS wrote:
> On 11/8/2019 7:24 PM, Bart wrote:

>>
>> It's possible to try it out; download these two source files to the 
>> same place:
>>
>>     https://raw.githubusercontent.com/sal55/qx/master/qq64.c (note 1.6MB)
>>     https://raw.githubusercontent.com/sal55/qx/master/merge.q
> 
> 
> I can never get that first one.  It takes forever to finish loading to 
> screen, and then it won't allow copy-paste.  Using Opera fwiw.
> 
> Can you save it as a file for download?

That's funny. Firefox is fine. Chrome will also display it quickly, but 
while it can copy parts, Ctrl-A doesn't work.

I've just downloaded Opera to try it; it seems to be buggy with its 
handling of large text files. (Even my own crappy little editor has no 
problem with 42K lines (it struggles a bit with 10M), and that is a 
program that is run under this same interpreter we're trying to download.)


(You can download the entire github repository as a ZIP, but that's a 
bit much, as there's lots of obsolete junk on there. Github doesn't seem 
to have a button to just download one file.)

If you can deal with ZIP files, try this:

    www.bcas.freeuk.com/qq64.zip        (260KB)

Extract the one file qq64.c. (On Opera, click on Downloads once 
complete, double click this file.)

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

#147841

On 11/9/2019 10:45 AM, Bart wrote:
> On 09/11/2019 14:44, DFS wrote:
>> On 11/8/2019 7:24 PM, Bart wrote:
> 
>>>
>>> It's possible to try it out; download these two source files to the 
>>> same place:
>>>
>>>     https://raw.githubusercontent.com/sal55/qx/master/qq64.c (note 
>>> 1.6MB)
>>>     https://raw.githubusercontent.com/sal55/qx/master/merge.q
>>
>>
>> I can never get that first one.  It takes forever to finish loading to 
>> screen, and then it won't allow copy-paste.  Using Opera fwiw.
>>
>> Can you save it as a file for download?
> 
> That's funny. Firefox is fine. Chrome will also display it quickly, but 
> while it can copy parts, Ctrl-A doesn't work.
> 
> I've just downloaded Opera to try it; it seems to be buggy with its 
> handling of large text files. (Even my own crappy little editor has no 
> problem with 42K lines (it struggles a bit with 10M), and that is a 
> program that is run under this same interpreter we're trying to download.)


I use Notepad++ (and Geany).  NP++ is great.


> (You can download the entire github repository as a ZIP, but that's a 
> bit much, as there's lots of obsolete junk on there. Github doesn't seem 
> to have a button to just download one file.)
> 
> If you can deal with ZIP files, try this:

I use 7zip now, used to use WinRAR.


>     www.bcas.freeuk.com/qq64.zip        (260KB)


Ever tried tinyupload.com ?


> Extract the one file qq64.c. (On Opera, click on Downloads once 
> complete, double click this file.)


heh!  What's with the 'tard instructions?

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

#147832

On 11/8/2019 7:24 PM, Bart wrote:
> On 08/11/2019 20:01, Bart wrote:
>> On 08/11/2019 18:15, DFS wrote:
>>> On 11/8/2019 12:53 PM, Bart wrote:
>>
>>
>>>> I wrote a merge-sort in my dynamic language 
>>>
>>>
>>> Pretty freakin' cool that you wrote your own language!
> 
>>> Is it feature-complete, or still a work in progress?
>>
>> (They're always a work in progress! But I no longer make them 
>> available via links as I sometimes did, as docs and support is too 
>> much work.)
> 
> It's possible to try it out; download these two source files to the same 
> place:
> 
>     https://raw.githubusercontent.com/sal55/qx/master/qq64.c (note 1.6MB)
>     https://raw.githubusercontent.com/sal55/qx/master/merge.q
> 
> Compile the C file using one of these commands in a console (I assume 
> you have 64-bit Windows):
> 
>     gcc -O3 qq64.c -oqq.exe

Took the better part of 30 seconds (on MSYS2)

gcc -Wall generates hundreds of warnings, which I'm sure you know.


>     tcc     qq64.c -oqq.exe -luser32

The usual < 1 second


> Then run that merge sort test:
> 
>     qq merge.q

compiled with tcc
N:=1 million
$ ptime qq bart_merge.q
Compiling bart_merge.q to bart_merge.pc
ISSORTED(A)= 1
Execution time: 28.182 s


compiled with gcc(MSYS2)
N:=1 million
$ ./qqgcc bart_merge.q
Compiling bart_merge.q to bart_merge.pc
ISSORTED(A)= 1
(no timing code, but I moved my lips and counted to 12 seconds)


> This is a representation of the 'Q' interpreter in 100% C code, so 
> doesn't include the acceleration I normally use that relies on inline 
> ASM. On my machine I get these values for N=10 million (you can edit 
> that inside merge.q especially to start to get a quicker test):
> 
>    gcc-O3       1   minute
>    tcc          3   minutes
>    (mine        1/2 minute using some inline ASM, otherwise no
>                     code optimisations at all)
> 
> (Performance with 100% HLL can be improved, but I normally use the 
> acceleration which is far more effective, so I haven't bothered.
> 
> I like making fairly elaborate programs accessible, via easy-to-compile 
> single files, and the above is one example. No makefiles are needed!)

Sweet little system.  Years of work I suppose.

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

#147842

On 09/11/2019 17:41, DFS wrote:
> On 11/8/2019 7:24 PM, Bart wrote:

>>     gcc -O3 qq64.c -oqq.exe
> 
> Took the better part of 30 seconds (on MSYS2)
> 
> gcc -Wall generates hundreds of warnings, which I'm sure you know.

Yeah. The main interest in these uploads of mine in the past has been 
how many warnings they could persuade gcc to generate, and how bad the 
code was.

This is machine-generated C code: a lot of these are things such as 
'unused labels', or things which are well-defined in the source 
language, but which C has decreed are undefined for reasons of its own.


>>     tcc     qq64.c -oqq.exe -luser32
> 
> The usual < 1 second

0.13 seconds on my PC, after doing it once or twice.

> 
>> Then run that merge sort test:
>>
>>     qq merge.q
> 
> compiled with tcc
> N:=1 million
> $ ptime qq bart_merge.q
> Compiling bart_merge.q to bart_merge.pc
> ISSORTED(A)= 1
> Execution time: 28.182 s
> 
> 
> compiled with gcc(MSYS2)
> N:=1 million
> $ ./qqgcc bart_merge.q
> Compiling bart_merge.q to bart_merge.pc
> ISSORTED(A)= 1
> (no timing code, but I moved my lips and counted to 12 seconds)

What machine are you using? These are figures I might get on my laptop. 
(Both my laptop and PC were the cheapest or second cheapest when I got 
them.)

BTW for timing on Windows, I used a 'timeit' C program, but which 
required parameters in quotes. This one doesn't need the quotes:

---------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <windows.h>

int main(int n, char** args) {
     int t;
     char *cmdline = GetCommandLine();

     while (*cmdline!=0 && *cmdline!=' ' && *cmdline!='\t') ++cmdline;

     if (*cmdline==0) exit(0);

     t=clock();
     system(cmdline);
     t=clock()-t;
     printf("%.2f",(double)t/1000);      // assumes msec ticks
}
---------------------------------------------

Call it something like tm.m, and compile to tm.exe (time.exe won't work 
as it is a Windows command). And run it like this:

   tm qq merge.q

(If you're feeling adventurous, try this binary version:

   www.bcas.freeuk.com/qq.zip      (230KB)

Unzip the one qq.exe file from qq.zip. This is built with my 
non-optimising non-C compiler, but it has the ASM accelerator module. 
However you might have trouble with anti-virus programs.)

>> I like making fairly elaborate programs accessible, via 
>> easy-to-compile single files, and the above is one example. No 
>> makefiles are needed!)
> 
> Sweet little system.  Years of work I suppose.

(The languages are the results of generations going back decades.

But the 'one-file' distribution idea started here about 5 years ago, 
when I got fed up with the sprawling distributions of open source 
software, that relied on impenetrable makefiles that never worked.

Half of them might also start off with a 20 or 30,000-line 'configure' 
bash script, which of course doesn't work on Windows. And I wasn't 
prepared to download half of Linux via CYGWIN or MSYS2 just to build a 
program that should be OS-independent anyway. The build system was just 
too complex.

So I decided that a program source distribution (not the original) 
should be as easy to build as a Hello, World program in hello.c:

     gcc hello.c -ohello.exe

So similar to downloading prog.exe as one binary file, which is well 
understood, but downloading prog.c as one source file instead. But many 
still don't get it.)

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

#147848

On 11/9/19 2:29 PM, Bart wrote:
> 
> This is machine-generated C code: a lot of these are things such as
> 'unused labels', or things which are well-defined in the source
> language, but which C has decreed are undefined for reasons of its own.

C has NOT said these are undefined. Unused Labels are perfectly legal
constructs in C, so no diagnostic is required, not is undefined behavior
generated. They are questionable in normal code, so a good
implementation can be made to generate a WARNING. The fact that is is
machine generated code says that it should normally be compiled at a
very low warning level. The only reason to compile machine generated
code at high warning levels is to work on the generation algorithm and
perhaps fix problems in it.

If you want your machine generated code to be able to be compiled at
higher warning levels without a lot of warnings, than you need to make
you generation system 'smarted' to not do the things that generate warnings.

As an aside, you CAN'T generally write code that generates absolutely
zero warnings with all implementations, in part because an
implementation is allowed to generate warnings for anything it wants,
and sometimes what is needed to eliminate a warning on one
implementation will generate a warning on another.

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

#147852

On 09/11/2019 19:59, Richard Damon wrote:
> On 11/9/19 2:29 PM, Bart wrote:
>>
>> This is machine-generated C code: a lot of these are things such as
>> 'unused labels', or things which are well-defined in the source
>> language, but which C has decreed are undefined for reasons of its own.
> 
> C has NOT said these are undefined. Unused Labels are perfectly legal
> constructs in C, so no diagnostic is required, not is undefined behavior
> generated. They are questionable in normal code, so a good
> implementation can be made to generate a WARNING. The fact that is is
> machine generated code says that it should normally be compiled at a
> very low warning level. The only reason to compile machine generated
> code at high warning levels is to work on the generation algorithm and
> perhaps fix problems in it.
> 
> If you want your machine generated code to be able to be compiled at
> higher warning levels without a lot of warnings, than you need to make
> you generation system 'smarted' to not do the things that generate warnings.

The new C generator I did in September did a lot of work to reduce 
warnings to zero on both Windows and Linux when gcc was run like this:

    gcc prog.c

Linux tended to be fussier, mainly because it picked up the mismatch 
between "%lld" and int64_t because int64_t was defined as 'long' on 
Linux. But now printf formats are not used in either generated code, or 
in explicit FFI calls in the original source.

And, generally there are very few warnings with:

    gcc -Wextra prog.c

These are ones I'm not so worried about, because they are largely 
erroneous. Eg:

     void fn(void) {
         int x;

         if (cond)
             x=10;
         else
             error();

         return x;
     }

where it reports that x may be used uninitialised.

Here the error() routine never returns, so it can never get to the 
return statement. This is difficult to both detect and fix in the code 
generator. (Always initialising local variables might do it, but I don't 
want to go that far.)

Anyway, my translator is designed to generate warning-free code with:

     gcc prog.c
     tcc prog.c
     bcc prog.c       (This one is easy as there are never warnings)

clang (which I no longer have), might be harder because last time I used 
it, all these extra warning flags seemed to be turned on by default.

Recommended compilers at present, which are generally available on both 
OSes, are gcc and tcc.

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

#147854

On 10/11/2019 11:00, Bart wrote:
> On 09/11/2019 19:59, Richard Damon wrote:
>>
>> If you want your machine generated code to be able to be compiled at
>> higher warning levels without a lot of warnings, than you need to make
>> you generation system 'smarted' to not do the things that generate warnings.
> 
> The new C generator I did in September did a lot of work to reduce
> warnings to zero on both Windows and Linux when gcc was run like this:
> 
>      gcc prog.c
> 
> Linux tended to be fussier, mainly because it picked up the mismatch
> between "%lld" and int64_t because int64_t was defined as 'long' on
> Linux. But now printf formats are not used in either generated code, or
> in explicit FFI calls in the original source.
> 
> And, generally there are very few warnings with:
> 
>      gcc -Wextra prog.c
> 
> These are ones I'm not so worried about, because they are largely
> erroneous. Eg:
> 
>       void fn(void) {
>           int x;
> 
>           if (cond)
>               x=10;
>           else
>               error();
> 
>           return x;
>       }
> 
> where it reports that x may be used uninitialised.
> 
> Here the error() routine never returns, so it can never get to the
> return statement. This is difficult to both detect and fix in the code
> generator. (Always initialising local variables might do it, but I don't
> want to go that far.)

As usual, gcc has a fix for that!

extern void error() __attribute__((noreturn));

-- 
Ian.

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

#147855

On 09/11/2019 22:24, Ian Collins wrote:
> On 10/11/2019 11:00, Bart wrote:

>> These are ones I'm not so worried about, because they are largely
>> erroneous. Eg:
>>
>>       void fn(void) {
>>           int x;
>>
>>           if (cond)
>>               x=10;
>>           else
>>               error();
>>
>>           return x;
>>       }
>>
>> where it reports that x may be used uninitialised.
>>
>> Here the error() routine never returns, so it can never get to the
>> return statement. This is difficult to both detect and fix in the code
>> generator. (Always initialising local variables might do it, but I don't
>> want to go that far.)
> 
> As usual, gcc has a fix for that!
> 
> extern void error() __attribute__((noreturn));
> 

Yes, I know. The problem is in dealing with it in a code generator, 
which may need the sort of code-path analysis that is in gcc.

(Actually I can't make gcc report that warning on a simple example like 
this, only within a huge program. Eg:

---------------------------
#include <stdio.h>
#include <stdlib.h>

extern void fn(void){exit(1);}
extern void fred(int a);
extern int abc;

int bill(void) {
     int x;
     if (abc)
         x=10;
     else
         fn();

     fred(x);        // maybe pass x uninitialised
     return x;       // and return it
}

int main(void) {
     printf("%d\n",bill());
}
--------------------------

'gcc -Wextra -Wall -Wpedantic -c' says nothing; why not? (I think I am 
compiling the right program...)

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

#147858

On 10/11/2019 11:48, Bart wrote:
> On 09/11/2019 22:24, Ian Collins wrote:
>> On 10/11/2019 11:00, Bart wrote:
> 
>>> These are ones I'm not so worried about, because they are largely
>>> erroneous. Eg:
>>>
>>>        void fn(void) {
>>>            int x;
>>>
>>>            if (cond)
>>>                x=10;
>>>            else
>>>                error();
>>>
>>>            return x;
>>>        }
>>>
>>> where it reports that x may be used uninitialised.
>>>
>>> Here the error() routine never returns, so it can never get to the
>>> return statement. This is difficult to both detect and fix in the code
>>> generator. (Always initialising local variables might do it, but I don't
>>> want to go that far.)
>>
>> As usual, gcc has a fix for that!
>>
>> extern void error() __attribute__((noreturn));
>>
> 
> Yes, I know. The problem is in dealing with it in a code generator,
> which may need the sort of code-path analysis that is in gcc.
> 
> (Actually I can't make gcc report that warning on a simple example like
> this, only within a huge program. Eg:
> 
> ---------------------------
> #include <stdio.h>
> #include <stdlib.h>
> 
> extern void fn(void){exit(1);}
> extern void fred(int a);
> extern int abc;
> 
> int bill(void) {
>       int x;
>       if (abc)
>           x=10;
>       else
>           fn();
> 
>       fred(x);        // maybe pass x uninitialised
>       return x;       // and return it
> }
> 
> int main(void) {
>       printf("%d\n",bill());
> }
> --------------------------
> 
> 'gcc -Wextra -Wall -Wpedantic -c' says nothing; why not? (I think I am
> compiling the right program...)

clang does a better job:
$ clang -Wall /tmp/x.c
/tmp/x.c:10:10: warning: variable 'x' is used uninitialized whenever 
'if' condition is false [-Wsometimes-uninitialized]
      if (abc)
          ^~~
/tmp/x.c:15:11: note: uninitialized use occurs here
      fred(x);        // maybe pass x uninitialised
           ^
/tmp/x.c:10:6: note: remove the 'if' if its condition is always true
      if (abc)
      ^~~~~~~~
/tmp/x.c:9:11: note: initialize the variable 'x' to silence this warning
      int x;
           ^
            = 0
1 warning generated.

One reason we always compile our code with clang as well as gcc...

-- 
Ian.

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

#147882

On 09/11/2019 23:48, Bart wrote:
> On 09/11/2019 22:24, Ian Collins wrote:
>> On 10/11/2019 11:00, Bart wrote:
> 
>>> These are ones I'm not so worried about, because they are largely
>>> erroneous. Eg:
>>>
>>>       void fn(void) {
>>>           int x;
>>>
>>>           if (cond)
>>>               x=10;
>>>           else
>>>               error();
>>>
>>>           return x;
>>>       }
>>>
>>> where it reports that x may be used uninitialised.
>>>
>>> Here the error() routine never returns, so it can never get to the
>>> return statement. This is difficult to both detect and fix in the code
>>> generator. (Always initialising local variables might do it, but I don't
>>> want to go that far.)
>>
>> As usual, gcc has a fix for that!
>>
>> extern void error() __attribute__((noreturn));
>>
> 
> Yes, I know. The problem is in dealing with it in a code generator, 
> which may need the sort of code-path analysis that is in gcc.
> 
> (Actually I can't make gcc report that warning on a simple example like 
> this, only within a huge program. Eg:
> 
> ---------------------------
> #include <stdio.h>
> #include <stdlib.h>
> 
> extern void fn(void){exit(1);}
> extern void fred(int a);
> extern int abc;
> 
> int bill(void) {
>      int x;
>      if (abc)
>          x=10;
>      else
>          fn();
> 
>      fred(x);        // maybe pass x uninitialised
>      return x;       // and return it
> }
> 
> int main(void) {
>      printf("%d\n",bill());
> }
> --------------------------
> 
> 'gcc -Wextra -Wall -Wpedantic -c' says nothing; why not? (I think I am 
> compiling the right program...)

gcc knows that "exit(1)" never returns, so "fn()" never returns, so "x" 
is never used without initialisation.

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

#147889

On 10/11/2019 13:46, David Brown wrote:
> On 09/11/2019 23:48, Bart wrote:

>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> extern void fn(void){exit(1);}
>> extern void fred(int a);
>> extern int abc;
>>
>> int bill(void) {
>>      int x;
>>      if (abc)
>>          x=10;
>>      else
>>          fn();
>>
>>      fred(x);        // maybe pass x uninitialised
>>      return x;       // and return it
>> }
>>
>> int main(void) {
>>      printf("%d\n",bill());
>> }
>> --------------------------
>>
>> 'gcc -Wextra -Wall -Wpedantic -c' says nothing; why not? (I think I am 
>> compiling the right program...)
> 
> gcc knows that "exit(1)" never returns, so "fn()" never returns, so "x" 
> is never used without initialisation.
> 

Originally fn() was just external, then I added the exit(1) bit:

-------------------------------------------
C:\c>type d.c
#include <stdio.h>
#include <stdlib.h>

extern void fn(void);
extern void fred(int a);
extern int abc;

int bill(void) {
     int x;
     if (abc)
         x=10;
     else
         fn();

     fred(x);        // maybe pass x uninitialised
     return x;       // and return it
}

int main(void) {
     printf("%d\n",bill());
}

C:\c>gcc -Wextra -Wall -Wpedantic -c d.c

C:\c>

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

#147911

On 10/11/2019 15:11, Bart wrote:
> On 10/11/2019 13:46, David Brown wrote:
>> On 09/11/2019 23:48, Bart wrote:
> 
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>>
>>> extern void fn(void){exit(1);}
>>> extern void fred(int a);
>>> extern int abc;
>>>
>>> int bill(void) {
>>>      int x;
>>>      if (abc)
>>>          x=10;
>>>      else
>>>          fn();
>>>
>>>      fred(x);        // maybe pass x uninitialised
>>>      return x;       // and return it
>>> }
>>>
>>> int main(void) {
>>>      printf("%d\n",bill());
>>> }
>>> --------------------------
>>>
>>> 'gcc -Wextra -Wall -Wpedantic -c' says nothing; why not? (I think I 
>>> am compiling the right program...)
>>
>> gcc knows that "exit(1)" never returns, so "fn()" never returns, so 
>> "x" is never used without initialisation.
>>
> 
> Originally fn() was just external, then I added the exit(1) bit:
> 
> -------------------------------------------
> C:\c>type d.c
> #include <stdio.h>
> #include <stdlib.h>
> 
> extern void fn(void);
> extern void fred(int a);
> extern int abc;
> 
> int bill(void) {
>      int x;
>      if (abc)
>          x=10;
>      else
>          fn();
> 
>      fred(x);        // maybe pass x uninitialised
>      return x;       // and return it
> }
> 
> int main(void) {
>      printf("%d\n",bill());
> }
> 
> C:\c>gcc -Wextra -Wall -Wpedantic -c d.c
> 
> C:\c>

You are correct - that spoils my simple explanation!

I did a little digging, and it seems this issue has been reported 
several times (with slight variations), but it turned out to be 
difficult to get a solution that didn't have false positives, and didn't 
affect other optimisations.  It is being worked on at the moment.

<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501>

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

#147856

Ian Collins <ian-news@hotmail.com> writes:
> On 10/11/2019 11:00, Bart wrote:
[...]
>> Here the error() routine never returns, so it can never get to the
>> return statement. This is difficult to both detect and fix in the code
>> generator. (Always initialising local variables might do it, but I don't
>> want to go that far.)
>
> As usual, gcc has a fix for that!
>
> extern void error() __attribute__((noreturn));

And C11 adds the _Noreturn keyword:

    extern _Noreturn void error(void);

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#147857

On 10/11/2019 11:53, Keith Thompson wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> On 10/11/2019 11:00, Bart wrote:
> [...]
>>> Here the error() routine never returns, so it can never get to the
>>> return statement. This is difficult to both detect and fix in the code
>>> generator. (Always initialising local variables might do it, but I don't
>>> want to go that far.)
>>
>> As usual, gcc has a fix for that!
>>
>> extern void error() __attribute__((noreturn));
> 
> And C11 adds the _Noreturn keyword:
> 
>      extern _Noreturn void error(void);

Even better!  I knew C++11 added the noreturn attribute, but didn't know 
about the C keyword.

-- 
Ian.

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

#147800

On 09/11/2019 06:53, Bart wrote:
> 
> Time to sort 10 million random integers:
> 
>     Interpreted:     33.7 seconds     (here 64-bit not 32-bit ints)
>     Your C++:         1.6 seconds     (using g++ -O3)
>     Your C++:        15.6 seconds     (using g++ -O0)
>     DFS C:            3.4 seconds     (using gcc -O3)
>     DFS C:            6.5 seconds     (using gcc -O0)
> 
> That 15.6 seconds figure is interesting: without optimising (and
> presumably reducing a huge amount of boilerplate code), the native-code
> C++ is barely double the speed of interpreted byte-code! And here all
> the action happens in byte-code too, not in some library.

No one runs unoptimised C++ code!  The language is designed to exploit 
optimisation, especially inlining.

-- 
Ian

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

Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11  Next page →

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

csiph-web