On 09/16/2016 03:19 PM, David Malcolm wrote:

When possible I don't think we want the tests to be target specific.
Hmm, I'm probably about to argue for Bernd's work...  The 71779
is a great example -- it uses high/lo_sum.  Not all targets support
-- as long as we don't try to recognize those insns we're likely OK,
that seems fragile long term.  Having an idealized target means we
ignore much of these issues.

An alternative would be to pick a specific target for each test.
It's an alternative, but not one I particularly like since those tests won't be consistently run. With an abstracted target like Bernd suggests we ought to be able to make most tests work with the abstracted target and minimize the number of truely target specific tests.

So I'm real curious, what happens if you run this RTL selftest under
valgrind?  I have the sneaking suspicion that we'll start doing some
uninitialized memory reads.

I'm seeing various leaks (an htab within linemap_init for all of the
line_table fixtures), but no uninitialized reads.
Wow.  I must say I'm surprised.  Good news though.

+  /* Dump taken from comment 2 of PR 71779, of
+     "...the relevant memory access coming out of expand"
+     with basic block IDs added, and prev/next insns set to
+     0 at ends.  */
+  const char *input_dump
+    = (";; MEM[(struct isl_obj *)&obj1] = &isl_obj_map_vtable;\n"
+       "(insn 1045 0 1046 2 (set (reg:SI 480)\n"
+       "        (high:SI (symbol_ref:SI (\"isl_obj_map_vtable\")
[flags 0xc0] <var_decl 0x7fa0363ea240 isl_obj_map_vtable>)))
y.c:12702 -1\n"
+       "     (nil))\n"
+       "(insn 1046 1045 1047 2 (set (reg/f:SI 479)\n"
+       "        (lo_sum:SI (reg:SI 480)\n"
+       "            (symbol_ref:SI (\"isl_obj_map_vtable\") [flags
0xc0] <var_decl 0x7fa0363ea240 isl_obj_map_vtable>))) y.c:12702
+       "     (expr_list:REG_EQUAL (symbol_ref:SI
(\"isl_obj_map_vtable\") [flags 0xc0] <var_decl 0x7fa0363ea240
+       "        (nil)))\n"
+       "(insn 1047 1046 1048 2 (set (reg:DI 481)\n"
+       "        (subreg:DI (reg/f:SI 479) 0)) y.c:12702 -1\n"
+       "     (nil))\n"
+       "(insn 1048 1047 1049 2 (set (zero_extract:DI (reg/v:DI 191
[ obj1D.17368 ])\n"
+       "            (const_int 32 [0x20])\n"
+       "            (const_int 0 [0]))\n"
+       "        (reg:DI 481)) y.c:12702 -1\n"
+       "     (nil))\n"
So looking at this just makes my head hurt.  Escaping, lots of
unnecessary things in the dump, etc.  The question I would have is
not have a file with the dump and read the file?


Seems like I need to add a mechanism for telling the selftests which
directory to load the tests relative to.
What about putting them inside the appropriate gcc.target directories? We could have one for the "generic" target assuming we build something like that, the others could live in their target specific directory.


Reply via email to