Patch ping

Message ID ZcX0CqFApBBo4zwD@tucnak
State Unresolved
Headers
Series Patch ping |

Checks

Context Check Description
snail/gcc-patch-check warning Git am fail log

Commit Message

Jakub Jelinek Feb. 9, 2024, 9:44 a.m. UTC
  Hi!

I'd like to ping 2 patches:

https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644580.html
PR113617 P1 - Handle private COMDAT function symbol reference in readonly data section

More details in the
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/thread.html#644121
and
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/thread.html#644486
threads.

and

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
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).

	Jakub
  

Comments

Jeff Law Feb. 12, 2024, 4:07 p.m. UTC | #1
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
  

Patch

--- 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++)