On Tue, Sep 02, 2025 at 04:51:37PM GMT, Jakub Jelinek wrote:
> On Tue, Aug 19, 2025 at 07:37:29PM +0800, Yang Yujie wrote:
> > This patch fixes regressions of the gcc.dg/torture/bitint-* tests
> > caused by r16-3036-ga76a032354ee48 with --enable-checking=all.
> > 
> > The errors are similar to the following:
> > 
> > ../../gcc/testsuite/gcc.dg/torture/bitint-14.c:54:1: error: type mismatch 
> > in 'array_ref'
> > <unnamed-signed:63>
> > 
> > unsigned long
> > 
> > _42 = VIEW_CONVERT_EXPR<unsigned long[10]>(r575[i_10])[8];
> > during GIMPLE pass: bitintlower0
> > ../../gcc/testsuite/gcc.dg/torture/bitint-14.c:54:1: internal compiler 
> > error: verify_gimple failed
> > 
> > Sorry about this.
> > 
> >     PR target/117599
> > 
> > gcc/ChangeLog:
> > 
> >     * gimple-lower-bitint.cc (bitint_large_huge::limb_access):
> >     Avoid emitting ARRAY_REF with the wrong element type.
> 
> That looks just too complicated.
> 
> What about the following instead?
> 
> The first two hunks aren't strictly necessary, I'm just trying to
> avoid calling build_qualified_type when it won't be needed.
> 
> At least on s390x-linux (tried cross) bitint-14.c doesn't ICE with it
> anymore.
> 
> Though, I must say the more I look at the limb_access changes, the less
> I like the abi_load_p stuff, so I think what we eventually should do instead
> is return values with m_limb_type always.
> For bitint_extended case (but only if we can prove that the extension there
> is for the right precision and right sign) or !write_p just return it,
> otherwise cast to lower precision and back to m_limb_type.
> And on the other side on stores, for !bitint_extended happily store whatever
> the whole m_limb_type value contains, for bitint_extended do the cast to
> smaller precision and back on the writes.

Hi Jakub,

Thanks for the simpler fix.  I was not sure what the last "else"
statement could hit.

The following patch removes the abi_load_p parameter, which was actually
a temporary thing because you said that we should do the optimizations
step-by-step.

https://gcc.gnu.org/pipermail/gcc-patches/2025-September/694405.html

Yujie

Reply via email to