N-dimensional array parameters and CilkPlus gcc

N-dimensional array parameters and CilkPlus gcc

I am checking out CilkPlus for usability, with the aim of giving a course on it, and want to ensure that what I teach is portable. Also, depending on where and how I give it, I may or may not have the Intel compilers on the system so need to be able to use CilkPlus gcc.

One of the more important aspects is matrix operations, which are very heavily used in scientific programming.  The following function definition is accepted by icc -std=c99, icpc and the CilkPlus version of gcc -std=c99 but not its g++.

    void fred (int m, int n, double a[m][n]);

I know the politics and technical issues, so let's skip them.  This is a major hit because it makes it impossible to write clean matrix functions (as in LAPACK).  Is there an option to enable this (though a source search doesn't show one), is it likely to be enhanced shortly, or is it a more permanent restriction?

10 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

Hi Nick,

      What error/output are you receiving when you try this in g++?

Thanks,

Balaji V. Iyer.

In 4.5.1:

wilder.c:1:36: error: array bound is not an integer constant before ']' token
wilder.c:1:39: error: array bound is not an integer constant before ']' token

In 4.8.0 (both the vanilla and CilkPlus version):

wilder.c:1:35: error: use of parameter 'm' outside function body
 void fred (int m, int n, double a[m][n]);
                                   ^
wilder.c:1:38: error: use of parameter 'n' outside function body
 void fred (int m, int n, double a[m][n]);

But I now find that I am also getting errors when I use section notation, so I suspect that something may have gone wrong when building it or I have a missing argument.  My build script assuredly puts the changes in, but there may be some incantation that I didn't see in the instructions.

Hello Nick,

     I tried a small test case (please see below) and it is failingj in with Cilk Plus disabled. Since this looks like an inherent GCC issue, it would be best if you could post this question in gcc mailing list (gcc-help @ gcc.gnu.org).

Thanks,

Balaji V. Iyer.

Here is the testcase I tried:

------------------------------------------------------------------------------

void fred (int m, int n, double a[m][n]);
int main (int argc, char **argv)
{
  return 0;
}

----------------------------------------------------------------

No, that's exactly what it ISN'T.  The point is that usage is a part of C99, but is NOT valid in C++; however, the Intel C++ compiler allows it as an extension.  There is therefore no fault or restriction in gcc, and this is a difference in the CilkPlus accepted by the Intel and gcc compilers; i.e. the CilkPlus extensions did not add this feature to bring gcc up to the functionality of Intel (in this respect, when compiling C++).

However, the absence of this feature means that it is impossible to write clean, size-generic matrix handling functions in CilkPlus g++, so has quite a serious impact.  That was why I asked whether this absence was temporary or permanent.

If you are interested, I can explain most of the political and technical background, but it's not critical to this issue.

Variable-length arrays (VLAs) are neither part of Cilk Plus nor part of standard C++.  The Intel compiler supports a subset of VLAs in C++ mode and g++ supports a smaller subset, but this support is not considered part of Cilk Plus, though I agree that it does make a nice combination with array notation.

The limitation in g++ is that you cannot pass a VLA as an argument to a function.  Here is a work-around that worked for me:

Instead of

void fred (int m, int n, double a[m][n]) { ... }

Write

void fred (int m, int n, void *va)
{
    double (*a)[n] = (double (*)[n]) va;
    ...
 }

I tried to find a prettier and more type-safe, but had limited success with that.

-Pablo

Thanks very much.  Obviously, I knew that it was not part of C++, but not that it's not part of CilkPlus.  It does mean that the CilkPlus language specification (1.1) is seriously misleading - perhaps even erroneous - because the first paragraph says that it specifies what extensions need to be provided and then gives VLAs as an example.  Please could you note my comment that it SHOULD be part of CilkPlus?

Thanks for your bypass - the problem is that is not the sort of thing to teach to the scientists that I teach.  I thought of several other approaches, but all failed for one reason or another :-(

Anyway, you have answered my question, so that I know what to say.

I have made a note of the fact that the Cilk Plus spec could be interpreted to imply that VLAs are part of Cilk Plus.  We'll try to correct that in the upcoming revision of the specification.

I have also made a note of your comment that VLAs in C++ SHOULD be part of the Cilk Plus specification.  This is a tricky point however.  The C++ standards committee has recently added very limited support for VLAs into most recent committee draft.  It is likely that this limited form will be part of the C++ standard in the next couple of years.  However, the draft does not include support for VLAs in argument lists.  We could, of course, add such an extension to the Cilk Plus specification, but I am concerned that we would be working at cross purposes with the C++ Standards Committee.

For C++, the standards committee has elected, instead, to create a dynarray library class.  It might make more sense for us to extend array-notation constructs to dynarray rather than extend VLAs in a way that is unpopular with the C++ standards committee.  More thought and experimentation are needed.

-Pablo

I agree that is a concern, but the problem is that dynarray is NOT a solution, as I pointed out in Bristol.  The problem is N-dimensional arrays, as always - dynarray needs to store the size somewhere and so a dynarray of dynarrays cannot be a contiguous MxN object, which is what it is in almost every other context.  In particular, that was the case in Fortran 77 and is in C, which are critical, because those are used for defining virtually every other interface - such as the one I am teaching today, MPI.

I agree with you that thought is needed, and an n-D dynarray class might do the job.  But, currently, I can't find any way of using unextended CilkPlus for matrix work that is reasonably teachable to people who are scientists first and C++ programmers second.

>> a contiguous MxN object, which is what it is in almost every other context.

Seeing that the MxN object (array of doubles) is required to be contiguous, then you need to declare your function prototype as:

void fred (int m, int n, double *a);

and call

fred(m,n,&a[0][0]);

Jim Dempsey

www.quickthreadprogramming.com

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen