On 2/9/24 02:44, Jakub Jelinek wrote:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644701.html
Introduce HOST_SIZE_T_PRINT_UNSIGNED etc. macros to fix LLP64 host build issue
Both have been successfully bootstrapped/regtested on x86_64-linux and
i686-linux, the latter has been tested by Jonathan on Windows too.
The alternative is start using %zu (AFAIK we only do that in libgccjit which
isn't supported everywhere and while it is C99, not sure if all supported
host C libraries support it), or change ira-conflicts.cc to
--- gcc/ira-conflicts.cc 2024-02-01 21:03:57.339193085 +0100
+++ gcc/ira-conflicts.cc 2024-02-09 10:41:39.201150644 +0100
@@ -151,8 +151,8 @@ build_conflict_bit_table (void)
fprintf
(ira_dump_file,
"+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n",
- (long) allocated_words_num * sizeof (IRA_INT_TYPE),
- (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE));
+ (long) (allocated_words_num * sizeof (IRA_INT_TYPE)),
+ (long) (object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)));
objects_live = sparseset_alloc (ira_objects_num);
for (i = 0; i < ira_max_point; i++)
Note, we have many more cases where we use %ld or %lu to print
size_t values (ideally %zd/%zu if we can assume it on all hosts, or
with the above introduced HOST_SIZE_T_PRINT*, the problem with the
%ld/%lu and casts is that it truncates the values on LLP64 hosts (aka
%Windows).
While I'd love to be able to use %z, I suspect it's going to be
problematical. That's one of the cleanups I need to have Mariam do on
the CRC code which uses %z extensively in its debugging dumps.
So let's assume %z is a no-go for now.
Having a HOST_SIZE_T_PRINT_UNSIGNED seems useful, so I'd tend to prefer
we go with that solution from the URL above rather than just throwing
some parens around the expression before casting the result to "long".
jeff
