On Fri, Nov 24, 2023 at 5:53 PM Andrew MacLeod <amacl...@redhat.com> wrote: > > This problem here is that IPA is calling something like operator_minus > with 2 operands, one with precision 32 (int) and one with precision 64 > (pointer). There are various ways this can happen as mentioned in the PR. > > Regardless of whether IPA should be doing promoting types or not calling > into range-ops, range-ops does not support mis-matched precision in its > arguments and it does not have to context to know what should be > promoted/changed. It is expected that the caller will ensure the > operands are compatible. > > However, It is not really practical for the caller to know this with > more context. Some operations support different precision or even > types.. ie, shifts, or casts, etc. It seems silly to require IPA to > have a big switch to see what the tree code is and match up/promote/or > bail if operands don't match... > > Range-ops routines probably shouldn't crash when this happens either, so > this patch takes the conservative approach and returns VARYING if there > is a mismatch in the arguments precision. > > Fixes the problem and bootstraps on x86_64-pc-linux-gnu with no new > regressions. > > OK for trunk? > > Andrew > > PS If you would rather we trap in these cases and fix the callers, then > I'd suggest we change these to checking_asserts instead. I have also > prepared a version that does a gcc_checking_assert instead of returning > varying and done a bootstrap/testrun. Of course, the callers will > have to be changed..
Yes, I'd very much prefer that - otherwise we get hard to find missed optimizations when one botches the argument (types). Richard. > > It bootstraps fine in that variation too, and all the testcases (except > this one of course) pass. Its clearly not a common occurrence, and my > inclination is to apply this patch so we silently move on and simply > don't provide useful range info.. that is all the callers in these cases > are likely to do anyway... > > > >
