[QUOTE]Aha - Mike's version has upper-left-to-lower-right-slanting `, whereas mine had standard single-quote ' - with the former it works.[/QUOTE][url]http://www.tldp.org/LDP/abs/html/commandsub.html[/url]

:max:

OK, all 3 .run files mentioned above now have been run successfully, after reboot, 'nvcc -V' gives
[i]
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2013 NVIDIA Corporation
Built on Wed_Jul_17_18:36:13_PDT_2013
Cuda compilation tools, release 5.5, V5.5.0
[/i]
Attempted nvcc compile of a couple basic sourcefiles indcates all is not well, however:
[i]
ewmayer@derek:~/Mlucas/SRC$ nvcc -c -O3 -DUSE_GPU util.cu gpu_iface.cu
In file included from imul_macro.h:29,
from mi64.h:30,
from util.h:32,
from util.cu:23:
imul_macro0.h:347:4: error: #error unknown compiler for AMD64.
util.cu:1080:5: error: #error unsupported compiler type for x87!
[/i]
Those preprocessor errors are due to the expected compiler-macro __CUDACC__ not being defined. So I tried using the list-predefines method described in post #4 in [url=http://www.mersenneforum.org/showthread.php?t=18668]this thread[/url]; that doesn't work for me, though:
[i]
ewmayer@derek:~/Mlucas/SRC$ strings nvcc | grep [-]D
strings: 'nvcc': No such file[/i]

Looks like the CUDA headers aren't in the compiler's default header path.

Try running nvcc with -L/usr/local/cuda-5.5/lib64

[QUOTE=Mark Rose;378814]Looks like the CUDA headers aren't in the compiler's default header path.

Try running nvcc with -L/usr/local/cuda-5.5/lib64[/QUOTE]

No joy - I tried putting the above path before and after the sourcefile names, and also tried just '.../lib32' on the thought that maybe nvcc was defaulting to 32-bit mode.

The lib32 and lib64 dirs are definitely there:
[code]
ewmayer@derek:~/Mlucas/SRC$ l /usr/local/cuda-5.5/lib64
libcublas_device.a libcudart.so.5.5 libcufftw.so libcurand.so libnppc.so libnpps.so
libcublas.so libcudart.so.5.5.22 libcufftw.so.5.5 libcurand.so.5.5 libnppc.so.5.5 libnpps.so.5.5
libcublas.so.5.5 libcudart_static.a libcufftw.so.5.5.22 libcurand.so.5.5.22 libnppc.so.5.5.22 libnpps.so.5.5.22
libcublas.so.5.5.22 libcufft.so libcuinj64.so libcusparse.so libnppi.so libnvToolsExt.so
libcudadevrt.a libcufft.so.5.5 libcuinj64.so.5.5 libcusparse.so.5.5 libnppi.so.5.5 libnvToolsExt.so.1
libcudart.so libcufft.so.5.5.22 libcuinj64.so.5.5.22 libcusparse.so.5.5.22 libnppi.so.5.5.22 libnvToolsExt.so.1.0.0
[/code]
But these are all link-time libs ... you say we need a path-to-headers, shouldn't that appear via -I[path] in the compile command, and point to a dir full of .h files?

p.s.: Mike just e-mailed to ask if "nvidia-smi" returns anything yet.

Yes - see below. Also the GPU fan kicked in from that, is still going a few mins later - shouldn't that die down after a few seconds, since there is no process running?

[code]ewmayer@derek:~/Mlucas/SRC$ nvidia-smi
Tue Jul 22 11:16:35 2014
+------------------------------------------------------+
| NVIDIA-SMI 5.319.37 Driver Version: 319.37 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 GeForce GT 430 Off | 0000:01:00.0 N/A | N/A |
| 65% 32C N/A N/A / N/A | 3MB / 1023MB | N/A Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Compute processes: GPU Memory |
| GPU PID Process name Usage |
|=============================================================================|
| 0 Not Supported |
+-----------------------------------------------------------------------------+[/code]

Updates:

o I couldn't find any way using nvidia-smi to shut the GPU fan back down after I did the above hardware diagnostics, so I simply waited for my ongoing Haswell Fermat-number run to hit its next savefile checkpoint and rebooted. Not a pretty solution, but it will serve for now (unless someone finds a better one). Perhaps I've been spoiled by the relative quietness of the Haswell fan - the case sits with side access panel removed (allowing easy access to the guts) on my desk, i.e. the CPU fan is literally 2 feet away from my head - but with all 4 cores blasting away, and the case fans nearest the CPU also running it's a quite tolerable noise level - nothing that interferes with me using a cellphone on the ear closest to the CPU. The GPU fan - and this is only an unloaded GT430! - was significantly louder than all 3 of the above fans together. But, on to config/compile issues.

o Looks like the "__CUDACC__ undefined" issue was due to some incorrect (in the context of GPU builds) nesting of #if-spaghetti in one of the headers used by my util.c ('ln -s'-aliased to util.cu) file. Next issue: nvcc is giving me errors about basic C typedefs, e.g.
[i]
gpu_iface.cu:30:3: warning: #warning using nvcc [-Wcpp]
gpu_iface.cu:32:4: warning: #warning device code trajectory [-Wcpp]
gpu_iface.cu:34:5: warning: #warning compiling with double precision [-Wcpp]
[b]types.h(354): error: expected a ";"[/b]

1 error detected in the compilation of "/tmp/tmpxft_00002ffa_00000000-6_gpu_iface.cpp1.ii".
[/i]
The error is for the first typedef in this snip, where I left-annotate with line numbers in the header file to make it easier to compare with the above nvcc error message:
[code]352 #if __CUDA_ARCH__ > 120
353 #warning CUDA: compiling with double precision
354 typedef real double;
355 typedef double vec_dbl;
356 #else
357 ...[/code]

The "typedef real to double" idea came to me via a CUDA forum earlier today, where it was done via #define - and indeed, changing
[i]
typedef real double;
[/i]
to
[i]
#define real double
[/i]
fixes that error - but now I get same kind of error for the next typedef on the next line. I don't want to change every typedef in my code to a #define -- this is after all standard C syntax!

[QUOTE=ewmayer;379006]Updates:

o I couldn't find any way using nvidia-smi to shut the GPU fan back down after I did the above hardware diagnostics, so I simply waited for my ongoing Haswell Fermat-number run to hit its next savefile checkpoint and rebooted. Not a pretty solution, but it will serve for now (unless someone finds a better one). Perhaps I've been spoiled by the relative quietness of the Haswell fan - the case sits with side access panel removed (allowing easy access to the guts) on my desk, i.e. the CPU fan is literally 2 feet away from my head - but with all 4 cores blasting away, and the case fans nearest the CPU also running it's a quite tolerable noise level - nothing that interferes with me using a cellphone on the ear closest to the CPU. The GPU fan - and this is only an unloaded GT430! - was significantly louder than all 3 of the above fans together. But, on to config/compile issues.

o Looks like the "__CUDACC__ undefined" issue was due to some incorrect (in the context of GPU builds) nesting of #if-spaghetti in one of the headers used by my util.c ('ln -s'-aliased to util.cu) file. Next issue: nvcc is giving me errors about basic C typedefs, e.g.
[i]
gpu_iface.cu:30:3: warning: #warning using nvcc [-Wcpp]
gpu_iface.cu:32:4: warning: #warning device code trajectory [-Wcpp]
gpu_iface.cu:34:5: warning: #warning compiling with double precision [-Wcpp]
[b]types.h(354): error: expected a ";"[/b]

1 error detected in the compilation of "/tmp/tmpxft_00002ffa_00000000-6_gpu_iface.cpp1.ii".
[/i]
The error is for the first typedef in this snip, where I left-annotate with line numbers in the header file to make it easier to compare with the above nvcc error message:
[code]352 #if __CUDA_ARCH__ > 120
353 #warning CUDA: compiling with double precision
354 typedef real double;
355 typedef double vec_dbl;
356 #else
357 ...[/code]

The "typedef real to double" idea came to me via a CUDA forum earlier today, where it was done via #define - and indeed, changing
[i]
typedef real double;
[/i]
to
[i]
#define real double
[/i]
fixes that error - but now I get same kind of error for the next typedef on the next line. I don't want to change every typedef in my code to a #define -- this is after all standard C syntax![/QUOTE]
Idea based on the IOCCC:

#define typedef #define

Do so after any #include line ...

May not work but worth a try :wink:

[QUOTE=ewmayer;379006]
354 typedef real double;
355 typedef double vec_dbl;
[/quote]

I think you mean 'typedef double real;' for the first one (IE 'create a type called 'real' which is another name for double')

[QUOTE=xilman;379023]#define typedef #define[/QUOTE]

Same thought occurred to me, but no go, because typedefs are ;-terminated.

[QUOTE=fivemack;379026]I think you mean 'typedef double real;' for the first one (IE 'create a type called 'real' which is another name for double')[/QUOTE]

I was simply flailing around yesterday afternoon, the forum where I saw that had '#define real double' which briefly (and incorrectly) led me to surmise that maybe nvcc used an internal 'master' floating-point type called 'real'. Again, makes no sense except in a "fog of war" kind of way.

So could someone please give me a straight answer to the question: Does nvcc support c-standard typedefs, or not?

If so, why would it squawk about something as simple as my example above?

If not I will have no choice but to monkey with a bunch of header files and carve out "special nvcc preprocessor section", but will be distinctly un-pleased by the need to do so.

[b]Update:[/b]

As most of the stuff in the above types.h file is unneeded for cuda compiles, I tried simply commenting out the include of that header in my gpu_iface.h file. Resulting compile gave just one missing typedef:
[i]
gpu_iface.h(74): error: identifier "int32" is undefined
[/i]
That is here in that header:
[i]
typedef struct {
int32 num_gpu;
gpu_info_t gpu_info[MAX_GPU];
} gpu_config_t;
[/i]
When I preceded that with the needed (i.e. copied over from types.h)
[i]
typedef int int32;
[/i]
It works just fine.

So maybe the real issue is that nvcc - perhaps some aspect of its 2-step compilation? - doesn't like the kind of headers-including-headers nesting I use?

If this is cribbed from cuda_xface.h in the Msieve source, the 'int32' is a typedef that Msieve makes up, it is in no way standard. You may be thinking of int32_t, which you get by including stdint.h, and which IIRC nvcc supports happily.

Incidentally, the CUDA runtime API now has a device query function that gives you absolutely all config information, something that didn't exist when I wrote my own crappy device query code.

[QUOTE=jasonp;379094]If this is cribbed from cuda_xface.h in the Msieve source, the 'int32' is a typedef that Msieve makes up, it is in no way standard. You may be thinking of int32_t, which you get by including stdint.h, and which IIRC nvcc supports happily.[/QUOTE]
The gpu_iface code is indeed cribbed from yours, but I have long had a full set of unambiguous-bitlength integer typedefs in my types.h header.

[QUOTE]Incidentally, the CUDA runtime API now has a device query function that gives you absolutely all config information, something that didn't exist when I wrote my own crappy device query code.[/QUOTE]
Thanks - will likely use that at some point, but right now am using the custom iface code as a means of testing my cuda tools install.

So, looking more closely at the sequence of typedefs in my types.h file: int32 is typedef'd right near the top and nvcc had no problem with it, nor others - except when it gets to the 'typedef double vec_dbl'.

Is vec_dbl perhaps an nvcc reserved word?

[Note: I don't really need a vector double type for cuda work since that will use the C scalar-double code I have in place - but in order to get SIMD and scalar-double code paths to play nice together, I find it useful to use a shared typedef (e.g. for allocs) which defaults to "length-1 vector' in the scalar case.]