https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119242
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 60740 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60740&action=edit gcc15-pr119242-wip.patch So I've played briefly with this PR and tried to convert the __int128 uses in the COBOL FE to FIXED_WIDE_INT(128), i.e. wide_int variant which is exactly 128-bit. This doesn't completely compile mainly because of binary_initial_from_float128/digits_from_float128/initial_from_float128 functions, so I don't really see how this PR can be fixed without also addressing PR119241 at the same time. I'm sure my formatting is off, in some cases I just didn't understand what the formatting rules are in the FE. What the FE does currently is definitely wrong even if it was ok to use __int128 in the FE (which it is not), all the build_int_cst_type calls with __int128 argument just lose the upper 64-bits of the value, built_int_cst_type's argument is HOST_WIDE_INT (i.e. signed 64-bit integer) or poly_int from that. So, as can be seen in the patch, one needs to use wide_int_to_tree instead and use a wide_int as argument. The unsigned char *pvalue = (unsigned char *)&value; ... if( *(uint64_t*)(pvalue + 8) ) etc. stuff is host endianity dependent, will work on little endian hosts only. Even if COBOL support is restricted to little endian targets only, one can still use big endian hosts to cross-compile it (or should be able). I really don't understand the /* GCC-13 has no provision for an int128 constructor. So, we use a union for our necessary __int128. hunk. GCC of course handles 128-bit INTEGER_CST initalizers just fine, at least provided build_int_cst_type isn't used which throws away all the upper bits. What the code did was again host endianity dependent. I don't see what during parsing of integral literals would verify they aren't too large to fit into signed (or unsigned if COBOL has such types?) 128-bit type and complain otherwise. The uses of atoi/atol in binary_initial_from_float128 look problematic to me as well, atoi will accept random garbage after the digits and doesn't properly signalize errors. Better use strtol/strtoll. We've tried hard recently to get rid of atoi etc. calls in the compiler. Another thing is are the *(signed int *)retval = atoi(ach); etc. stores done with those, that seems that retval is malloced host memory one stores some host dependent endianity data in and I haven't searched how they are used later, if they are emitted as blob into binaries which can have different endianity from the host. Also, the assumption that host long is 64-bit is just wrong (I've changed that temporarily to long long and atoll). The normal GCC way would be return tree with INTEGER_CST or REAL_CST or something similar, something that can be handled later by the middle-end.
