On Fri, Jan 30, 2026 at 11:16:18AM +0100, Richard Biener wrote:
> On Fri, 30 Jan 2026, Jakub Jelinek wrote:
>
> > On Thu, Jan 29, 2026 at 06:59:34PM +0800, Jason Merrill wrote:
> > > I guess since NULLPTR_TYPE is in tree.def it makes sense for
> > > fold_convert_loc to handle it.
> >
> > Here is a fold-const.cc version of that.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> OK. I'll note that POINTER_TYPE_P does not cover NULLPTR_TYPE, so
> there might be interesting effects if such constants leak throughout
> the ME. But I do see few cases where it's already handled.
It is correct that POINTER_TYPE_P does not cover NULLPTR_TYPE, that
is not a pointer type, just a weirdo type that most of the time
doesn't leak into ME because conversion from decltype(nullptr) to
pointers or integers result in zero INTEGER_CST regardless of the
value of the argument (with side-effects evaluated of course).
So, usually NULLPTR_TYPE leaks into ME when there is variable
with that type like:
decltype(nullptr) a;
or when a struct/union contains decltype(nullptr) member and it
can leak to the ME say on
decltype(nullptr) a, b;
void foo () { a = b; }
where ME sees a = 0; both with NULLPTR_TYPE.
Or of course for debug info too.
Jakub
