This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] cilkplus array notation for C (clean, independent patchset, take 1)

All these builtins need to be documented in doc/.


+initialize builtin functions are stored in @file{array-notation-common.c}.  In
+the current array notation implementation there are 12 builtin reduction
+operations.  Details about these functions and their usage are available in
+the Cilk Plus language specification at @w{@uref{}}.
+@itemize @bullet
+@item __sec_reduce_add
+@item __sec_reduce_mul
+@item __sec_reduce_max
+@item __sec_reduce_min
+@item __sec_reduce_max_ind

First, the common documentation idiom is "built-in" not builtin. Second, these should be documented in extend.texi along with the rest of the builtins listed there.

As I'd mentioned, you have .exp files named compile.exp and execute.exp which
seem to be causing ambiguity problems in parallel checks (make check -jN).  For
some reason, with this patch, the rest of dg.exp fails to run after Cilkplus'
compile/execute.exp runs.  Renaming these to something less generic does the
trick.  Do you mind prefixing all the .exp's with "cilkplus_" or something similar?

FIXED! I added the "cilkplus_AN_c_" prefix to everything, where "an" stands for Array Notation . This way it won't interfere with the future Cilk Plus patches' test case.

I think eventually all the compile tests for all of cilkplus should go in one directory and one for the execute tests. There is no need for a separate directory for the array notation, etc, etc. For that matter, we should probably munge everything into one dg style directory. But this is ok for now.

--- a/gcc/testsuite/gcc.dg/cilk-plus/array_notation/compile/array_test2.c
+++ b/gcc/testsuite/gcc.dg/cilk-plus/array_notation/compile/array_test2.c
@@ -26,7 +26,7 @@ int main(int argc, char **argv)
       array[ii] = 10;
       array2[ii] = 5000000;
-  array2[0:10:2] = array[0:10:2];
+  array2[0:5:2] = array[0:5:2];

What is this non-related change?

If these are mere syntax error tests, I suggest you get rid of all the optimization
variants.  Surely there is no need to test the error at -O, then at -O2, etc.  -O0
should suffice.  For that matter, you shouldn't pass any optimization flag and let
the test itself set the flags with "// dg-options" or whatever in the test itself (if
for some reason you have a test that has one particular error only reportable at
some optimization level).

I did this purely as a safety measure for the commonly used flags that I know of. If it won't cause too much of a problem I would like to keep it.

All these errors are in the front-end, so optimization shouldn't matter. It just seems like over kill to run 750 tests for just 15 individual .c files. We can leave this for now.

And please make sure there are no regressions on the branch when checking
with "make check -k -jN" (N > 1) and for a plain serial check-- at least while we
iron out this dejagnu setup.

It works for make -j8 check on my 8 core machine.

I assume "make -j1" still works and has no regressions?

Can you repost an updated (and tested) patch?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]