I use a lot of templates for my kernel and get segmentation faults from nvopencc now and then and i am running
out of workarounds for the most recent one.
is there a way to use the gcc frontend to open64 in the hope that it can handle more of the c++ spec?
does it make sense to file a bug report for code that uses “too much” c++?
thanks for your help :)
I use a lot of templates for my kernel and get segmentation faults from nvopencc now and then and i am running
out of workarounds for the most recent one.
is there a way to use the gcc frontend to open64 in the hope that it can handle more of the c++ spec?
does it make sense to file a bug report for code that uses “too much” c++?
thanks for your help :)
as i just saw from gfec -version it is already gcc 3.3.1, so is there a chance to
get a more recent gcc to work?
I use a lot of templates for my kernel and get segmentation faults from nvopencc now and then and i am running
out of workarounds for the most recent one.
is there a way to use the gcc frontend to open64 in the hope that it can handle more of the c++ spec?
does it make sense to file a bug report for code that uses “too much” c++?
thanks for your help :)
well according to the releasenotes of 2.1, templates are supported, so if you have problems with templates you can file them as bugs indeed.
I use a lot of templates for my kernel and get segmentation faults from nvopencc now and then and i am running
out of workarounds for the most recent one.
is there a way to use the gcc frontend to open64 in the hope that it can handle more of the c++ spec?
does it make sense to file a bug report for code that uses “too much” c++?
thanks for your help :)
if you or google is interested in the solution:
i compiled open64 (with gcc-3.x frontend) from cuda 2.1 from download.nvidia.com with gcc-4.3.2
and the segfault went away.
asm
March 22, 2009, 9:46am
5
if you or google is interested in the solution:
i compiled open64 (with gcc-3.x frontend) from cuda 2.1 from download.nvidia.com with gcc-4.3.2
and the segfault went away.
it’s very interesting… because I also experimented with nvopencc.
I managed to add some useful intrinsics that is missing in original CUDA, such as:
__mul24hi, __addo, __addc
I wonder… did you get the open64 sources from public svn ? How did you compile the CUDA backend ?
Actually I had couple of problems with compiling NVISA target because some special cases
are just not implemented (especially floating-point) and one needs a good bit of intuition
to realize how this works…
it’s very interesting… because I also experimented with nvopencc.
I managed to add some useful intrinsics that is missing in original CUDA, such as:
__mul24hi, __addo, __addc
I wonder… did you get the open64 sources from public svn ? How did you compile the CUDA backend ?
Actually I had couple of problems with compiling NVISA target because some special cases
are just not implemented (especially floating-point) and one needs a good bit of intuition
to realize how this works…
as i wrote: download.nvidia.com
compilation was: cd osprey/targia3264_nvisa; make (or sth like this)
the compilation threw a few error messages (missing includes) and i stopped fixing more errors after i got
gfec, be, inline compiled.
when i compiled from open64-4.2.1 from open64.net (sf,net http download) i had to uncomment some floating point stuff too which
was probably not implemented, but the resulting compiler was only 32bit and did not produce the same
computational results for my kernel, although the assembler was quite the same (with respect to semantics,
not label names). i stopped comparing the output when i found out by accident that the nividia source tree
worked also. so i am happy for now with the result. i was not able to find nvisa 64bit in the official open64
distribution. as long as the compiler does not explode again i do not intend to do further research into
open64.