https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #8 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #7) > On Wed, 5 Aug 2020, rsandifo at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373 > > > > --- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot > > gnu.org> --- > > FWIW, I think the reason I mentioned for skimping on this originally > > was that we don't e.g. prevent if-conversion of: > > > > void > > foo (int *c, float *f) > > { > > for (int i = 0; i < 16; ++i) > > f[i] = c[i] ? __builtin_sqrtf (f[i]) : f[i]; > > } > > > > for -O2 -ftree-vectorize -fno-math-errno. So it seemed like things > > weren't very consistent. > > I think that's a bug in if-conversion - gimple_could_trap_p only > says that the call instruction itself doesn't trap, it doesn't > say anything about something in the callee body. When's that distinction useful in practice though? It seems odd that an FP x / y is seen as potentially trapping, but a function call that wraps (or might wrap) an FP x / y isn't. > You should need -fno-trapping-math to get the above if-converted. Is there an existing ECF flag that we can check? ECF_NOTHROW is related but seems different enough not to be reliable. And is trapping a “side effect“ for the purposes of: /* Nonzero if this is a call to a function whose return value depends solely on its arguments, has no side effects, and does not read global memory. This corresponds to TREE_READONLY for function decls. */ #define ECF_CONST (1 << 0) I.e. can a function still be const (on the basis that a given argument always produces the same result) while still trapping for some arguments? What about pure, where the trapping might come from a memory dereference?
