Thanks Jakub for reviewing, sorry for misleading and will have a try for PATCH 
v3.

Pan

-----Original Message-----
From: Jakub Jelinek <ja...@redhat.com> 
Sent: Monday, June 19, 2023 5:17 PM
To: Li, Pan2 <pan2...@intel.com>
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; rdapp....@gmail.com; 
jeffreya...@gmail.com; Wang, Yanzhang <yanzhang.w...@intel.com>; 
kito.ch...@gmail.com; rguent...@suse.de
Subject: Re: [PATCH] RISC-V: Fix out of range memory access of machine mode 
table

On Mon, Jun 19, 2023 at 05:05:48PM +0800, pan2...@intel.com wrote:
> --- a/gcc/lto-streamer-in.cc
> +++ b/gcc/lto-streamer-in.cc
> @@ -1985,7 +1985,8 @@ lto_input_mode_table (struct lto_file_decl_data 
> *file_data)
>      internal_error ("cannot read LTO mode table from %s",
>                   file_data->file_name);
>  
> -  unsigned char *table = ggc_cleared_vec_alloc<unsigned char> (1 << 8);
> +  unsigned char *table = ggc_cleared_vec_alloc<unsigned char> (
> +    MAX_MACHINE_MODE);

Incorrect formatting.  And, see my other mail, this is wrong.

> @@ -108,7 +108,7 @@ inline void
>  bp_pack_machine_mode (struct bitpack_d *bp, machine_mode mode)
>  {
>    streamer_mode_table[mode] = 1;
> -  bp_pack_enum (bp, machine_mode, 1 << 8, mode);
> +  bp_pack_enum (bp, machine_mode, MAX_MACHINE_MODE, mode);
>  }
>  
>  inline machine_mode
> @@ -116,7 +116,8 @@ bp_unpack_machine_mode (struct bitpack_d *bp)
>  {
>    return (machine_mode)
>          ((class lto_input_block *)
> -         bp->stream)->mode_table[bp_unpack_enum (bp, machine_mode, 1 << 8)];
> +         bp->stream)->mode_table[bp_unpack_enum (bp, machine_mode,
> +                                                 MAX_MACHINE_MODE)];
>  }

And these two are wrong as well.  The value passed to bp_pack_enum
has to match the one used on bp_unpack_enum.  But that is not the case
after your changes.  You stream out with the host MAX_MACHINE_MODE, and
stream in for normal LTO with the same value (ok), but for offloading
targets (nvptx, amdgcn) with a different MAX_MACHINE_MODE.  That will
immediate result in LTO streaming being out of sync and ICEs all around.
The reason for using 1 << 8 there was exactly to make it interoperable for
offloading.  What could be perhaps done is that you stream out the
host MAX_MACHINE_MODE value somewhere and stream it in inside of
lto_input_mode_table before you allocate the table.  But, that streamed
in host max_machine_mdoe has to be remembered somewhere and used e.g. in
bp_unpack_machine_mode instead of MAX_MACHINE_MODE.

        Jakub

Reply via email to