Just out of curiosity I tried to compile the following:
example.cc:
extern "C" {
int serious_subroutine() {
for (int i = 0; i < 1000000; ++i) {
int j = i*i;
}
return 8;
}
int serious_subroutine_() __attribute__ ((weak, alias
("serious_subroutine")));
int serious_subroutine__() __attribute__ ((weak, alias
("serious_subroutine")));
} // extern "C"
using g++ 3.4.6 and icpc 10.1.022 -- in both cases I got
nm example.o
00000000 T serious_subroutine
00000000 W serious_subroutine_
00000000 W serious_subroutine__
which means that icpc does understand __attribute__ (...) and,
consequently, this can be probably given a try if the problem
is "to be able to use either gnu or intel compilers to build
pmemd with CUDA support".
Best,
Volodymyr
On Mon, March 29, 2010 13:03, Robert Duke wrote:
> Yeah, that is what I am worried about - vendor compilers don't necessarily
> conform to gcc, so finding stuff to use in gcc is not a great idea.
> Adhering to certain c standards is a better idea, but I know that at least
> in the past, the functionality found in c preprocessors was still "hit and
> miss", to describe it kindly. So we just need to look out for this. If
> anyone is still using something old, they might try it and see what
> happens.
> I used to hit old ibm and and sgi machines for this purpose, but I don't
> have them anymore.
> Regards -Bob
>
> ----- Original Message -----
> From: "Volodymyr Babin" <vbabin.ncsu.edu>
> To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
> Sent: Monday, March 29, 2010 12:37 PM
> Subject: Re: [AMBER-Developers] Help with NVIDIA Compilation using ifort
>
>
>>> The only issue I can think
>>> of is if there is a c preprocessor out there somewhere that can't
>>> handle
>>> stringizing - that may be why I avoided doing this in the first pass.
>>
>> A good point to look for a quite portable solution is "gmacros.h" from
>> glib (http://library.gnome.org/devel/glib/), I believe.
>>
>> Another way would be to use gcc's "alias" __attribute__
>>
>> http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Function-Attributes.html#Function-Attributes
>>
>> alias ("target")
>> The alias attribute causes the declaration to be emitted as an alias
>> for another symbol, which must be specified. For instance,
>>
>> void __f () { /* Do something. */; }
>> void f () __attribute__ ((weak, alias ("__f")));
>>
>>
>> defines `f' to be a weak alias for `__f'. In C++, the mangled name
>> for
>> the target must be used. It is an error if `__f' is not defined in the
>> same translation unit.
>>
>> Not all target machines support this attribute.
>>
>> Just random comments,
>>
>> Volodymyr
>>
>>> Some
>>> folks who use a wider variety of platforms than I do might want to
>>> comment
>>> on that.
>>> Regards - Bob
>>> ----- Original Message -----
>>> From: "Volodymyr Babin" <vbabin.ncsu.edu>
>>> To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
>>> Sent: Monday, March 29, 2010 12:18 PM
>>> Subject: RE: [AMBER-Developers] Help with NVIDIA Compilation using
>>> ifort
>>>
>>>
>>>> One could possibly use a macro like
>>>>
>>>> #ifdef ASSUME_JUST_ONE_TRAILING_UNDERSCORE
>>>> # define FORTRANIZE(name) name##_
>>>> #else
>>>> # define FORTRANIZE(name) name##___
>>>> #endif
>>>>
>>>> or something like that.
>>>>
>>>> Best,
>>>>
>>>> Volodymyr
>>>>
>>>> On Mon, March 29, 2010 11:59, Ross Walker wrote:
>>>>> Hi Tim
>>>>>
>>>>> We already have something similar to this in
>>>>> src/pmemd/src/cuda/gpu.cpp
>>>>>
>>>>> extern "C" void gpu_dump_dval_(double* pDouble)
>>>>> {
>>>>> ...
>>>>> }
>>>>>
>>>>> I was hoping to find a way to do this without having to go through
>>>>> and
>>>>> make
>>>>> additional copies of everything for Intel.
>>>>>
>>>>> All the best
>>>>> Ross
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: amber-developers-bounces.ambermd.org [mailto:amber-developers-
>>>>>> bounces.ambermd.org] On Behalf Of Timothy J Giese
>>>>>> Sent: Friday, March 26, 2010 4:15 PM
>>>>>> To: AMBER Developers Mailing List
>>>>>> Subject: Re: [AMBER-Developers] Help with NVIDIA Compilation using
>>>>>> ifort
>>>>>>
>>>>>> I've only done a few things with cuda/fortran, but I basically
>>>>>> treat it like how I treat c/fortran, i.e., in C, create
>>>>>> subroutine_ and have it simply call subroutine.
>>>>>>
>>>>>> I've never really thought about pros and cons of this.
>>>>>>
>>>>>> For example
>>>>>>
>>>>>> void init_template_kernel_drv(int &, int &, int &);
>>>>>> void free_template_kernel_drv();
>>>>>> void run_template_kernel_drv(int &, double *);
>>>>>>
>>>>>> extern "C"
>>>>>> {
>>>>>> void init_template_kernel_(int &, int &, int &);
>>>>>> void free_template_kernel_();
>>>>>> void run_template_kernel_(int &, double *);
>>>>>> }
>>>>>>
>>>>>>
>>>>>> void init_template_kernel_(int & max_blocks,int & threads_per_block,
>>>>>> int
>>>>>> & buflen)
>>>>>> {
>>>>>> init_template_kernel_drv(max_blocks, threads_per_block, buflen);
>>>>>> }
>>>>>>
>>>>>> void free_template_kernel_()
>>>>>> {
>>>>>> free_template_kernel_drv();
>>>>>> }
>>>>>>
>>>>>>
>>>>>> void run_template_kernel_(int & na, double * A)
>>>>>> {
>>>>>> run_template_kernel_drv(na, A);
>>>>>> }
>>>>>>
>>>>>>
>>>>>> I found some discussion on the intel boards. Not sure how
>>>>>> useful it is.
>>>>>>
>>>>>> http://software.intel.com/en-us/forums/showthread.php?t=56872
>>>>>>
>>>>>> -Tim
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> AMBER-Developers mailing list
>>>>>> AMBER-Developers.ambermd.org
>>>>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> AMBER-Developers mailing list
>>>>> AMBER-Developers.ambermd.org
>>>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> AMBER-Developers mailing list
>>>> AMBER-Developers.ambermd.org
>>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> AMBER-Developers mailing list
>>> AMBER-Developers.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>>
>>
>>
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>
>>
>
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Mar 29 2010 - 11:00:02 PDT
