«

This is actually for a homework assignment in CUDA, but I have pinned
down the problem to a single statement, the only statement in the
program that is long enough that it needs to be split into multiple
lines.

void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float* deviceA,
float* deviceB, float* deviceC,
int numARows, int numAColumns,
int numBRows, int numBColumns,
int numCRows, int numCColumns);

The part in <<< >>> is CUDA-specific.

I haven't found any newsgroup for CUDA, but since it is one of the
languages derived from C, I assume that an answer for C will also
work in CUDA.

The statement is a function call, and cannot be split into multiple
statements.

What should I do to split the statement? Just adding end-of-lines
after the commas only produces confusing error messages about an
incomplete type.

Removing the void at the beginning only gives a different confusing
error message.

In case it matters, I am editing the program under Windows and
running it on a remote system that I suspect is running Linux.

I have the K&R2 book, just not time enough to search through all
of it by the time this is due.

By the way, are any of you interested in a free online CUDA course?

Heterogeneous Parallel Programming
https://www.coursera.org/category/cs-programming

Already on progress, but another one is planned in 2013.

Robert Miles wrote:
> This is actually for a homework assignment in CUDA, but I have pinned
> down the problem to a single statement, the only statement in the
> program that is long enough that it needs to be split into multiple
> lines.
>
> void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float* deviceA,
> float* deviceB, float* deviceC,
> int numARows, int numAColumns,
> int numBRows, int numBColumns,
> int numCRows, int numCColumns);
>
> The part in <<< >>> is CUDA-specific.
>
> I haven't found any newsgroup for CUDA, but since it is one of the
> languages derived from C, I assume that an answer for C will also
> work in CUDA.
>
> The statement is a function call, and cannot be split into multiple
> statements.
>
> What should I do to split the statement? Just adding end-of-lines
> after the commas only produces confusing error messages about an
> incomplete type.

If it were C, you wouldn't be getting error messages, so your problem
must be CUDA specific.

--
Ian Collins

On 12/25/2012 08:21 PM, Robert Miles wrote:
> This is actually for a homework assignment in CUDA, but I have pinned
> down the problem to a single statement, the only statement in the
> program that is long enough that it needs to be split into multiple
> lines.
>
> void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float* deviceA,
> float* deviceB, float* deviceC,
> int numARows, int numAColumns,
> int numBRows, int numBColumns,
> int numCRows, int numCColumns);
>
> The part in <<< >>> is CUDA-specific.
>
> I haven't found any newsgroup for CUDA, but since it is one of the
> languages derived from C, I assume that an answer for C will also
> work in CUDA.
>
> The statement is a function call, and cannot be split into multiple
> statements.
>
> What should I do to split the statement? Just adding end-of-lines
> after the commas only produces confusing error messages about an
> incomplete type.

If the relevant rules in CUDA were the same as in C, you could rewrite
that statement as follows, without any change to its meaning:

void
matrixMultiply
dim3
DimGrid
,
dim3
DimBlock
(
float
*
deviceA
,
float
*
deviceB
,
float
*
deviceC
,
int
numARows
,
int
numAColumns
,
int
numBRows
,
int
numBColumns
,
int
numCRows
,
int
numCColumns
)
;

Therefore, if If that doesn't work in CUDA, then CUDA is too different
from C for you to get useful advice on this issue from someone who knows
C, but not CUDA.

> Removing the void at the beginning only gives a different confusing
> error message.

That's easier to deal with. In C, the declaration of a function starts
with either the type of it's return value, or the keyword 'void'
indicating that it has no return value. Remove 'void' from the code
above, and it no longer satisfies that rule. CUDA apparently has similar
rules.

> In case it matters, I am editing the program under Windows and
> running it on a remote system that I suspect is running Linux.

That might matter; Windows and Linux platforms have different
conventions for terminating lines. If you transferred the program
without using some method for converting the line endings, it might
confuse CUDA. Some linux systems have a utility called dos2unix for
performing such a conversion. ftp has a 'cr' command which toggles
whether or not it performs the necessary conversion. I've no idea what
options are available on the Windows side.
--
James Kuyper

Robert Miles <> writes:
> This is actually for a homework assignment in CUDA, but I have pinned
> down the problem to a single statement, the only statement in the
> program that is long enough that it needs to be split into multiple
> lines.
>
> void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float* deviceA,
> float* deviceB, float* deviceC,
> int numARows, int numAColumns,
> int numBRows, int numBColumns,
> int numCRows, int numCColumns);
>
> The part in <<< >>> is CUDA-specific.
>
> I haven't found any newsgroup for CUDA, but since it is one of the
> languages derived from C, I assume that an answer for C will also
> work in CUDA.
>
> The statement is a function call, and cannot be split into multiple
> statements.

If you delete the <<< ... >>> part, what remains is a valid C function
*declaration*, not a function call (and not a statement).

A C compiler would not care how the declaration is split into lines, as
long as it's split between tokens. (A human reader will care about
readability.)

> What should I do to split the statement? Just adding end-of-lines
> after the commas only produces confusing error messages about an
> incomplete type.
>
> Removing the void at the beginning only gives a different confusing
> error message.
>
> In case it matters, I am editing the program under Windows and
> running it on a remote system that I suspect is running Linux.
>
> I have the K&R2 book, just not time enough to search through all
> of it by the time this is due.

You won't find the answer to this in K&R2. Your problem is either
specific to CUDA or, as James Kuyper suggests, a result of the
difference in the way Windows and Linux represent line endings.

What happens if you *don't* split the declaration, i.e., leave
it as one very long line? It would be about 200 characters long,
well within the minimum that all C compilers are required to accept.
(I have no idea whether CUDA imposes stricter limits). Splitting it
into multiple lines is certainly a good idea, but it could be useful
to see what happens if you don't.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 26/12/12 02.21, Robert Miles wrote:
....
> What should I do to split the statement? Just adding end-of-lines
> after the commas only produces confusing error messages about an
> incomplete type.
>
> Removing the void at the beginning only gives a different confusing
> error message.
>
> In case it matters, I am editing the program under Windows and
> running it on a remote system that I suspect is running Linux.
.....

Hi Robert

Maybe the problem is different end-of-line representations.

TextWrangler on Mac OS X can clean up mixed representations between old
MacOS, Windows/DOS and Linux - by converting three times between all
three - and then converting to e.g. Linux representations.

Programmer’s Notepad:
http://www.pnotepad.org/features/
Quote: "...
Support for windows, unix and macintosh line endings
...."

Representations:
http://en.wikipedia.org/wiki/Newline#Representations

Conversion utilities:
http://en.wikipedia.org/wiki/End_of_...sion_utilities

Unix2dos:
http://en.wikipedia.org/wiki/Unix2dos

-

It is simply incredible that all macros and compilers can not handle
"wrong" end-of-line representations.

The symptoms I encountered was also different types of
inconsistent/"impossible" error messages, that disappeared when the
"wrong" end-of-line representations was removed.

I am sure many cross-platform code migraters struggle, when they start it.

Glenn

Robert Miles <> writes:

> This is actually for a homework assignment in CUDA, but I have pinned
> down the problem to a single statement, the only statement in the
> program that is long enough that it needs to be split into multiple
> lines.
>
> void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float*
> deviceA, float* deviceB, float* deviceC,
> int numARows, int numAColumns,
> int numBRows, int numBColumns,
> int numCRows, int numCColumns);
>
> The part in <<< >>> is CUDA-specific.
>
> I haven't found any newsgroup for CUDA, but since it is one of the
> languages derived from C, I assume that an answer for C will also
> work in CUDA.
>
> The statement is a function call, and cannot be split into multiple
> statements.

Just one point. This is not a CUDA call. A call to CUDA "kernel"
function looks exactly like a C funtion call but as an "execution
configuration" (the <<<...>>> thing) inserted before the brackets.
I.e. (as has been said) you need to drop the "void" for it to be a call.

> What should I do to split the statement?

You may be confused by what a statement is. You seem to be talking
about splitting a statement into multiple lines -- that's not that same
thing at all; it's still one statement, just written differently.

<snip>
--
Ben.

Ben Bacarisse <> writes:
> Robert Miles <> writes:
>
>> This is actually for a homework assignment in CUDA, but I have pinned
>> down the problem to a single statement, the only statement in the
>> program that is long enough that it needs to be split into multiple
>> lines.
>>
>> void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float*
>> deviceA, float* deviceB, float* deviceC,
>> int numARows, int numAColumns,
>> int numBRows, int numBColumns,
>> int numCRows, int numCColumns);
>>
>> The part in <<< >>> is CUDA-specific.
>>
>> I haven't found any newsgroup for CUDA, but since it is one of the
>> languages derived from C, I assume that an answer for C will also
>> work in CUDA.
>>
>> The statement is a function call, and cannot be split into multiple
>> statements.
>
> Just one point. This is not a CUDA call. A call to CUDA "kernel"
> function looks exactly like a C funtion call but as an "execution
> configuration" (the <<<...>>> thing) inserted before the brackets.
> I.e. (as has been said) you need to drop the "void" for it to be a call.

Dropping the "void" isn't enough to make it a call; you also have to
replace the parameter declarations with expressions of appropriate type.

[...]

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 12/27/2012 11:35 AM, Keith Thompson wrote:
> Ben Bacarisse <> writes:
>> Robert Miles <> writes:
>>
>>> This is actually for a homework assignment in CUDA, but I have pinned
>>> down the problem to a single statement, the only statement in the
>>> program that is long enough that it needs to be split into multiple
>>> lines.
>>>
>>> void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float*
>>> deviceA, float* deviceB, float* deviceC,
>>> int numARows, int numAColumns,
>>> int numBRows, int numBColumns,
>>> int numCRows, int numCColumns);
>>>
>>> The part in <<< >>> is CUDA-specific.
>>>
>>> I haven't found any newsgroup for CUDA, but since it is one of the
>>> languages derived from C, I assume that an answer for C will also
>>> work in CUDA.
>>>
>>> The statement is a function call, and cannot be split into multiple
>>> statements.
>>
>> Just one point. This is not a CUDA call. A call to CUDA "kernel"
>> function looks exactly like a C funtion call but as an "execution
>> configuration" (the <<<...>>> thing) inserted before the brackets.
>> I.e. (as has been said) you need to drop the "void" for it to be a call.
>
> Dropping the "void" isn't enough to make it a call; you also have to
> replace the parameter declarations with expressions of appropriate type.

Given that it needs so many changes to become a function call, it seems
more likely that it was intended to be a function declaration, and that
Robert just made a mistake when he referred to it as a function call.
He also called it a statement, which in C would require that it be a
function call, not a function declaration; but perhaps CUDA is more like
C++, which has declaration-statements.

On 12/26/2012 12:59 AM, Robert Miles wrote:
> On 12/25/2012 9:15 PM, James Kuyper wrote:
>> On 12/25/2012 08:21 PM, Robert Miles wrote:
>>> This is actually for a homework assignment in CUDA, but I have pinned
>>> down the problem to a single statement, the only statement in the
>>> program that is long enough that it needs to be split into multiple
>>> lines.
>>>
>>> void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float* deviceA,
>>> float* deviceB, float* deviceC,
>>> int numARows, int numAColumns,
>>> int numBRows, int numBColumns,
>>> int numCRows, int numCColumns);
>>>
>>> The part in <<< >>> is CUDA-specific.
>>>
>>> I haven't found any newsgroup for CUDA, but since it is one of the
>>> languages derived from C, I assume that an answer for C will also
>>> work in CUDA.
>>>
>>> The statement is a function call, and cannot be split into multiple
>>> statements.
>>>
>>> What should I do to split the statement? Just adding end-of-lines
>>> after the commas only produces confusing error messages about an
>>> incomplete type.
>>
>> If the relevant rules in CUDA were the same as in C, you could rewrite
>> that statement as follows, without any change to its meaning:
>>
>> void
>> matrixMultiply
>> dim3
>> DimGrid
>> ,
>> dim3
>> DimBlock
>> (
>> float
>> *
>> deviceA
>> ,
>> float
>> *
>> deviceB
>> ,
>> float
>> *
>> deviceC
>> ,
>> int
>> numARows
>> ,
>> int
>> numAColumns
>> ,
>> int
>> numBRows
>> ,
>> int
>> numBColumns
>> ,
>> int
>> numCRows
>> ,
>> int
>> numCColumns
>> )
>> ;
>>
>> Therefore, if If that doesn't work in CUDA, then CUDA is too different
>> from C for you to get useful advice on this issue from someone who knows
>> C, but not CUDA.
>
> You forgot the <<< and >>>, which ARE CUDA-specific.

No, I didn't forget, you only said that "The part in <<< >>> is
CUDA-specific." The <<< and >>> tokens are not IN that part, they
delimit that part. I thought that what you meant was that those
delimeters were your own notation for our benefit, not that they were
part of CUDA syntax. What you should have said "The part from <<< to >>>
is CUDA-specific".

>>> Removing the void at the beginning only gives a different confusing
>>> error message.
>>
>> That's easier to deal with. In C, the declaration of a function starts
>> with either the type of it's return value, or the keyword 'void'
>> indicating that it has no return value. Remove 'void' from the code
>> above, and it no longer satisfies that rule. CUDA apparently has similar
>> rules.
>
> Looks like you didn't notice that it is supposed to be a function
> call, not a function definition.

I noticed that you referred to it as a function call, and as a
statement, but I also noticed that, as far as C is concerned, it has
(ignoring the CUDA-specific features), the syntax of a C function
declaration, which is NOT a statement type. That left me quite uncertain
as to what it was "supposed" to be, so I just paid attention to what it
actually was (as far as C is concerned).

I've learned that it's generally more useful to pay attention to what
the code says than what newbies say about the code, because they often
don't know the right words to use when talking about it. For instance,
you words above suggest a confusion about the difference between a
function declaration and a function definition.

The 'void' would be an error in a C function call, while the absence of
any specification of the return type would require a diagnostic in any
version of C later than C90 if it were a C function declaration.
Therefore, if you didn't get an error message about the 'void' keyword
when it was present, and if removing the 'void' caused a different error
message, there's a good chance CUDA interprets the syntax in a similar
fashion.

> I've now rewritten it as:
>
> matrixMultiply <<<DimGrid,DimBlock>>> (deviceA, deviceB, deviceC,
> numARows, numAColumns,
> numBRows, numBColumns,
> numCRows, numCColumns);

That, on the other hand, does have the syntax of a function call.

> This at least stops the compile errors, but leaves an execution error
> later. This may be enough that I can finish debugging it tonight.

Good luck.