Hi Tobias, On 7/18/2025 3:16 PM, Tobias Burnus wrote:
I am wondering whether we should implement it – for kind=1 (and at least for set len=1) by a call to BUILT_IN_MEMCHR / BUILT_IN_MEMRCHR. For set len > 1, a loop around it has to be generated, and for kind=4, it could be implemented manual walk of the array elements (+ another loop for set len > 1).
I don't have a strong opinion on whether split/tokenize should be implemented as compiler intrinsics. It seems LLVM's Flang maintainers also believe these functions belong in a vendor support library rather than being compiler intrinsics.
Either way, I've already learned a lot about adding procedure intrinsics to gfortran from working on the split patch! If we decide not to implement these, should we at least add a replacement recommendation to the intrinsic documentation?
I'm open to spending more time on c_f_pointer's new optional argument. I initially looked at both split/tokenize and c_f_pointer and found split/tokenize seemed a bit simpler, which is why I started there. If Interoperability with C is something you believe merits implementation in gfortran, I'd be happy to work on it, and I might even reach out for your help or ideas since you implemented this feature 12 years ago :)
Also, if you have some free time, could you please help review the two previous patches for the trig-pi functions fallback? I believe most issues with the libgfortran patch have been resolved (I used the correct autoconf version to regenerate the script). This patch would allow users without glibc >= 2.41 to use the trig-pi functions. For the libquadmath patch, I think the implementation approach is sound. The only question is whether the current glibc's generic implementation is robust enough to be included in libquadmath. Personally, I think we can add this as a starting point, and if glibc provides a better implementation in the future, we can easily update ours using the script.
Thanks in advance for your time! Best regards, Yuao
