On Fri, Jun 14, 2024 at 3:21 AM Li, Pan2 <pan2...@intel.com> wrote:
>
> Thanks for another try.
>
> Looks the build failure list below has nothing to do with this patch. I think
> the correlated owner will take care of this Werror build issue soon.
>
> Pan
>
> -----Original Message-----
> From: Maciej W. Rozycki <ma...@orcam.me.uk>
> Sent: Friday, June 14, 2024 12:15 AM
> To: Li, Pan2 <pan2...@intel.com>
> Cc: Richard Biener <richard.guent...@gmail.com>; gcc-patches@gcc.gnu.org;
> juzhe.zh...@rivai.ai; kito.ch...@gmail.com; tamar.christ...@arm.com
> Subject: RE: [PATCH v7] Match: Support more form for scalar unsigned SAT_ADD
>
> On Thu, 13 Jun 2024, Li, Pan2 wrote:
>
> > Could you please help to update the upstream for another try ?
> >
> > Should be fixed by this commit
> > https://github.com/gcc-mirror/gcc/commit/d03ff3fd3e2da1352a404e3c53fe61314569345c.
> >
> > Feel free to ping me if any questions or concerns.
>
> Upstream master (as at 609764a42f0c) doesn't build:
>
> In file included from .../gcc/gcc/coretypes.h:487,
> from .../gcc/gcc/tree-vect-stmts.cc:24:
> In member function 'bool poly_int<N, T>::is_constant() const [with unsigned
> int N = 2; C = long unsigned int]',
> inlined from 'C poly_int<N, T>::to_constant() const [with unsigned int N
> = 2; C = long unsigned int]' at .../gcc/gcc/poly-int.h:588:3,
> inlined from 'bool get_group_load_store_type(vec_info*, stmt_vec_info,
> tree, slp_tree, bool, vec_load_store_type, vect_memory_access_type*,
> poly_int64*, dr_alignment_support*, int*, gather_scatter_info*,
> internal_fn*)' at .../gcc/gcc/tree-vect-stmts.cc:2155:39,
> inlined from 'bool get_load_store_type(vec_info*, stmt_vec_info, tree,
> slp_tree, bool, vec_load_store_type, unsigned int, vect_memory_access_type*,
> poly_int64*, dr_alignment_support*, int*, gather_scatter_info*,
> internal_fn*)' at .../gcc/gcc/tree-vect-stmts.cc:2387:38:
> .../gcc/gcc/poly-int.h:557:7: error: 'remain.poly_int<2, long unsigned
> int>::coeffs[1]' may be used uninitialized [-Werror=maybe-uninitialized]
> 557 | if (this->coeffs[i] != 0)
> | ^~
> .../gcc/gcc/tree-vect-stmts.cc: In function 'bool
> get_load_store_type(vec_info*, stmt_vec_info, tree, slp_tree, bool,
> vec_load_store_type, unsigned int, vect_memory_access_type*, poly_int64*,
> dr_alignment_support*, int*, gather_scatter_info*, internal_fn*)':
> .../gcc/gcc/tree-vect-stmts.cc:2115:23: note: 'remain.poly_int<2, long
> unsigned int>::coeffs[1]' was declared here
> 2115 | poly_uint64 remain;
> | ^~~~~~
> In file included from .../gcc/gcc/system.h:1250,
> from .../gcc/gcc/tree-vect-stmts.cc:23:
> In function 'int ceil_log2(long unsigned int)',
> inlined from 'bool get_group_load_store_type(vec_info*, stmt_vec_info,
> tree, slp_tree, bool, vec_load_store_type, vect_memory_access_type*,
> poly_int64*, dr_alignment_support*, int*, gather_scatter_info*,
> internal_fn*)' at .../gcc/gcc/tree-vect-stmts.cc:2156:43,
> inlined from 'bool get_load_store_type(vec_info*, stmt_vec_info, tree,
> slp_tree, bool, vec_load_store_type, unsigned int, vect_memory_access_type*,
> poly_int64*, dr_alignment_support*, int*, gather_scatter_info*,
> internal_fn*)' at .../gcc/gcc/tree-vect-stmts.cc:2387:38:
> .../gcc/gcc/hwint.h:266:17: error: 'remain.poly_int<2, long unsigned
> int>::coeffs[0]' may be used uninitialized [-Werror=maybe-uninitialized]
> 266 | return x == 0 ? 0 : floor_log2 (x - 1) + 1;
> | ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> .../gcc/gcc/tree-vect-stmts.cc: In function 'bool
> get_load_store_type(vec_info*, stmt_vec_info, tree, slp_tree, bool,
> vec_load_store_type, unsigned int, vect_memory_access_type*, poly_int64*,
> dr_alignment_support*, int*, gather_scatter_info*, internal_fn*)':
> .../gcc/gcc/tree-vect-stmts.cc:2115:23: note: 'remain.poly_int<2, long
> unsigned int>::coeffs[0]' was declared here
> 2115 | poly_uint64 remain;
> | ^~~~~~
> cc1plus: all warnings being treated as errors
> make[2]: *** [Makefile:1198: tree-vect-stmts.o] Error 1
>
> and actually e14afbe2d1c6^ doesn't build either (I guess it's just slipped
> through bisection as the file didn't have to be rebuild or something):
>
> In file included from .../gcc/gcc/rtl.h:3973,
> from .../gcc/gcc/config/riscv/riscv.cc:31:
> In function 'rtx_def* init_rtx_fmt_ee(rtx, machine_mode, rtx, rtx)',
> inlined from 'rtx_def* gen_rtx_fmt_ee_stat(rtx_code, machine_mode, rtx,
> rtx)' at ./genrtl.h:50:26,
> inlined from 'void riscv_move_integer(rtx, rtx, long int, machine_mode)'
> at .../gcc/gcc/config/riscv/riscv.cc:2786:10:
> ./genrtl.h:37:16: error: 'x' may be used uninitialized
> [-Werror=maybe-uninitialized]
> 37 | XEXP (rt, 0) = arg0;
> .../gcc/gcc/config/riscv/riscv.cc: In function 'void riscv_move_integer(rtx,
> rtx, long int, machine_mode)':
> .../gcc/gcc/config/riscv/riscv.cc:2723:7: note: 'x' was declared here
> 2723 | rtx x;
> | ^
> cc1plus: all warnings being treated as errors
> make[2]: *** [Makefile:2563: riscv.o] Error 1
>
> I hope you'll find this all useful. As it happens I don't need to verify
> my needs with a RISC-V target anymore, so I'm leaving it all up to you now
> as I need to switch back to Alpha, which has been my actual objective, and
> these rebuilds have taken a lot of my attention already.
I'm including
@@ -2148,15 +2148,17 @@ get_group_load_store_type (vec_info *vinfo,
stmt_vec_info stmt_info,
...
if (!nunits.is_constant (&cnunits)
|| !LOOP_VINFO_VECT_FACTOR (loop_vinfo).is_constant (&cvf)
- || ((cremain = remain.to_constant (), true)
+ || (((cremain = group_size * cvf - gap % cnunits), true)
&& ((cpart_size = (1 << ceil_log2 (cremain))) != cnunits)
in a patch I'm testing that should eventually fix the above bogus diagnostic.
> Thank you for your input.
>
> Maciej
