spavloff wrote: > > > The strictfp function attribute is not enough. We found that we needed > > > the attribute on every function call because some transform passes were > > > working on a BasicBlock that didn't belong to a function at the time we > > > were checking for the function attribute. I'd hate for us to get back > > > into a situation where compiles are perfectly fine except for when > > > strictfp is used and then LLVM crashes with a NULL pointer dereference. > > > Such cases won't be caught until after LLVM is out in the field simply > > > because most LLVM developers aren't thinking about strictfp and we can't > > > expect them to start. > > > > I don't believe that particular manifestation of the problem will occur -- > > if we're going to see a NULL pointer crash from not having a Function, it > > would not be dependent on strictfp attribute being present -- because the > > crash would arise from checking whether strictfp is present! And the > > current patch checks for NULL function before querying its attributes. > > And that is what happened. A transform pass assumed non-NULL Function pointer > and crashed checking for strictfp. I'm worried that other passes will do the > same and won't be caught until after LLVM ships. And I'm worried because > there's nothing stopping this bug from being introduced in new places.
Such a case indeed occurs in functions doing const-folding because that perform constant folding, because folding may be invoked early, when the IR is being constructed and the enclosing function is not yet specified. The check for strictfp suitable for constant folding must handle this case as well (which is implemented in #190478). For this PR such check is not needed, because the checks happen in the memory-effects queries, where the enclosing function is defined. https://github.com/llvm/llvm-project/pull/188297 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
