On Fri, Mar 17, 2023 at 12:53:48PM +0000, Richard Biener wrote: > On Fri, 17 Mar 2023, Jakub Jelinek wrote: > > > On Fri, Mar 17, 2023 at 01:18:32PM +0100, Richard Biener wrote: > > > The following adds a missing range-op for __builtin_expect which > > > helps -Wuse-after-free to detect the case a realloc original > > > pointer is used when the result was NULL. > > > > > > Bootstrap and regtest running on x86_64-unknown-linux-gnu, OK? > > > > > > PR tree-optimization/109170 > > > * gimple-range-op.cc (cfn_expect): New. > > > (gimple_range_op_handler::maybe_builtin_call): Handle > > > __builtin_expect. > > > > > > * gcc.dg/Wuse-after-free-pr109170.c: New testcase. > > > > Shouldn't that be something we handle generically for all > > ERF_RETURNS_ARG calls (and not just for irange, but for any > > supported ranges)? > > > > Though, admittedly __builtin_expect probably doesn't set that > > and all the other current builtins with ERF_RETURNS_ARG return > > pointers I think. > > Looking at builtin_fnspec we're indeed missing BUILT_IN_EXPECT, > but we could indeed use gimple_call_fnspec and look for a > returned argument. If it's not the first handling this > generically is going to be interesting wrt op?_range though, > so we'd need a range operator for each case (returns arg 1, > returns arg 2, more args are not supported?). Currently
I think fnspec supports 1-4, but nothing actually uses anything but 1 or none; I could be wrong. Anyway, I think it is fine to implement __builtin_expect this way for now, ERF_RETURNS_ARG will be more important for pointers, especially if we propagate something more than just maybe be/can't be/must be null. Don't you need to handle BUILT_IN_EXPECT_WITH_PROBABILITY the same though? > all returns-arg builtins return the first arg, but eventually > modref or the fortran frontend will end up with calls returning > sth else. > > If a float arg is returned it also needs to be a frange operator, > right? Jakub