[PUSHED] nvptx: Build libgfortran with '-mfake-ptx-alloca' [PR107635]

[Andre Vehreschild]

Hi Harald,

my "rant" was more about "Why would one spend time with a library meant for
testing only." I totally agree that the one code base approach is one fine
way to go. I didn't not want to insult anyone and apologize, if I did.

Finally this discussion made me think, what it would need to have a coarray
library that makes use of a GPU, i.e. to really formulate the parallel code
for nvptx with coarrays and how the expressions would need to look like.
Any thoughts about that?

Regards,
Andre

Andre Vehreschild * vehre@gmx.de
Am 28. Februar 2025 20:40:40 schrieb Harald Anlauf <anlauf@gmx.de>:

> Am 28.02.25 um 08:24 schrieb Andre Vehreschild:
>> Hi Thomas,
>>
>> are you really telling me, that gfortran's coarray test library is compiled for
>> offloading to GPU (or other SIMD processors)? Because that's what NVPTX is used
>> for most, right? In my opinion that makes no sense, because coarrays in Fortran
>> are used for SISD style accesses. Although the new style now extracts "kernels"
>> for the access (which are tiny; and therefore should not perform on any GPU),
>> I'd rather expect the caf_single library to be not compiled for
>> NVPTX-offloading. Are there different opinions?
>
> Why not?  Some people develop code using a single-source approach, so
> they can use (Fortran standard) coarrays, as well as directive-driven
> offloading.  I don't see anything wrong with that.
>
> Some other compiler (NAG) enables coarrays by default(!).
>
> So is there any reason *not* to require that the caf_single library
> is - at least in principle - available on *all* targets?
>
> Cheers,
> Harald
>
>> Sorry, for disturbing the NVPTX build. I wasn't aware, that it was done for
>> caf_*.
>>
>> Regards,
>> 	Andre

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/fortran/attachments/20250228/4fb00bc5/attachment-0001.htm>