Created attachment 50931 [details] Fortran code showing problem Hi All! Fails in too many different ways... Should work at least as CFI_type_other... Seen on: GNU Fortran (GCC) 10.3.1 20210526 (ICE) GNU Fortran (GCC) 11.1.1 20210526 GNU Fortran (GCC) 12.0.0 20210529 (experimental) Thank you very much. Best regards, José Rui
Created attachment 50932 [details] C code for bind(c)
On my system I get % gfc pr100907.f90 pr100907.c pr100907.c:4:10: fatal error: uchar.h: No such file or directory 4 | #include <uchar.h> | ^~~~~~~~~ compilation terminated.
It seems that Mac OS doesn't have the full set of C11 standard headers... :-( It should work using "stdint.h" and typedef(ing) char32_t to uint32_t. If that doesn't work either one could try "unsigned int". I will attach an updated file, with the altered file. I have no access to Mac OS, so I cannot test it. Thank you very much. Best regards, José Rui
Created attachment 50954 [details] Mac OS support
> It seems that Mac OS doesn't have the full set of C11 standard headers... :-( Shouldn't the C11 standard headers be provide by GCC12? Nevertheless the test compiles with the new version of the new C companion. The same is true for 100910 and 100914.
> Shouldn't the C11 standard headers be provide by GCC12? > AFAIK gcc uses the system's libc. In Linux the default will be GNU libc "glibc" in Mas OS the default libc will be BSD libc which is missing some of the headers... Or so it says in GNU portability library "gnulib" documentation... Thank you very much. Best regards, José Rui
Created attachment 51000 [details] Patch and changelog
The master branch has been updated by Sandra Loosemore <sandra@gcc.gnu.org>: https://gcc.gnu.org/g:93b6b2f614eb692d1d8126ec6cb946984a9d01d7 commit r12-3321-g93b6b2f614eb692d1d8126ec6cb946984a9d01d7 Author: Sandra Loosemore <sandra@codesourcery.com> Date: Wed Aug 18 07:22:03 2021 -0700 libgfortran: Further fixes for GFC/CFI descriptor conversions. This patch is for: PR100907 - Bind(c): failure handling wide character PR100911 - Bind(c): failure handling C_PTR PR100914 - Bind(c): errors handling complex PR100915 - Bind(c): failure handling C_FUNPTR PR100917 - Bind(c): errors handling long double real All of these problems are related to the GFC descriptors constructed by the Fortran front end containing ambigous or incomplete information. This patch does not attempt to change the GFC data structure or the front end, and only makes the runtime interpret it in more reasonable ways. It's not a complete fix for any of the listed issues. The Fortran front end does not distinguish between C_PTR and C_FUNPTR, mapping both onto BT_VOID. That is what this patch does also. The other bugs are related to GFC descriptors only containing elem_len and not kind. For complex types, the elem_len needs to be divided by 2 and then mapped onto a real kind. On x86 targets, the kind corresponding to C long double is different than its elem_len; since we cannot accurately disambiguate between a 16-byte kind 10 long double from __float128, this patch arbitrarily prefers to interpret that as the standard long double type rather than the GNU extension. Similarly, for character types, the GFC descriptor cannot distinguish between character(kind=c_char, len=4) and character(kind=ucs4, len=1). But since the front end currently rejects anything other than len=1 (PR92482) this patch uses the latter interpretation. 2021-09-01 Sandra Loosemore <sandra@codesourcery.com> José Rui Faustino de Sousa <jrfsousa@gmail.com> gcc/testsuite/ PR fortran/100911 PR fortran/100915 PR fortran/100916 * gfortran.dg/PR100911.c: New file. * gfortran.dg/PR100911.f90: New file. * gfortran.dg/PR100914.c: New file. * gfortran.dg/PR100914.f90: New file. * gfortran.dg/PR100915.c: New file. * gfortran.dg/PR100915.f90: New file. libgfortran/ PR fortran/100907 PR fortran/100911 PR fortran/100914 PR fortran/100915 PR fortran/100917 * ISO_Fortran_binding-1-tmpl.h (CFI_type_cfunptr): Make equivalent to CFI_type_cptr. * runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc): Fix handling of CFI_type_cptr and CFI_type_cfunptr. Additional error checking and code cleanup. (gfc_desc_to_cfi_desc): Likewise. Also correct kind mapping for character, complex, and long double types.
Jose's test case for this issue is still failing.
(In reply to sandra from comment #9) > Jose's test case for this issue is still failing. Which is not surpising: sz = (size_t)auxp->elem_len / sizeof (char); for kind=4 character of len=1 and len=7 gives sz=4 and sz=28. The testcase should have used: sz = (size_t)auxp->elem_len / sizeof (CFI_type_ucs4_char); Or expect 4 and 28 instead of 1 and 7 as result ...
In both case I get FAIL! chrcmp: 66 != 65281 FAIL! chrcmp: 66 != 65281 FAIL! chrcmp: 67 != 65282 FAIL! chrcmp: 68 != 65283 FAIL! chrcmp: 69 != 65284 FAIL! chrcmp: 70 != 65285 FAIL! chrcmp: 71 != 65286 FAIL! chrcmp: 72 != 65287 FAIL! chrcmp: 73 != 65288 FAIL! chrcmp: 74 != 65289 FAIL! chrcmp: 75 != 65290 FAIL! chrcmp: 0 != 65291 FAIL! char: 75 != 11 Assertion failed: (c_vrfy_character (auxp)), function check_tk, file pr100907_db.c, line 215. Program received signal SIGABRT: Process abort signal.