https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #18 from Mikael Morin <mikael at gcc dot gnu.org> --- Created attachment 55662 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55662&action=edit Updated tentative patch This fixes comment #4 as well, but the failure on value_9 remains on 32 bit powerpc. It is almost testsuite clean on x86_64. There is a regression on c_char_tests_2.f03 because there is a hole in the handling of single char values in gfc_conv_procedure_call. Length one arguments are handled with: 6436 else if (fsym && fsym->attr.value) 6437 { 6438 if (fsym->ts.type == BT_CHARACTER 6439 && fsym->ts.is_c_interop 6440 && fsym->ns->proc_name != NULL 6441 && fsym->ns->proc_name->attr.is_bind_c) 6442 { .... // Pass single char value 6447 } 6448 else 6449 { 6450 gfc_conv_expr (&parmse, e); 6451 .... 6456 if (!fsym->ts.is_c_interop 6457 && gfc_length_one_character_type_p (&fsym->ts)) 6458 { .... // pass single char value The failing case is when the type is interoperable (character(c_char)), but the procedure is not bind(c). So the translation from string to single character is neither done in the if branch (the procedure is not bind(c)) nor in the if of the else branch (the type is interoperable).
