nathanchance added a comment. In D105169#3246378 <https://reviews.llvm.org/D105169#3246378>, @nlopes wrote:
> In D105169#3244624 <https://reviews.llvm.org/D105169#3244624>, @nathanchance > wrote: > >> I can reduce all of these down for you and/or I can start an email thread >> with the `objtool` maintainers to see if there is a way to fix or avoid >> these warnings on the `objtool` side and include you in that discussion, if >> LLVM is not really doing anything wrong here. I am by no means an expert in >> this area and I don't want to delay this anymore but I want to avoid >> regressing our builds, as `objtool` regularly helps us spot compiler bugs. >> Perhaps @nickdesaulniers has some other thoughts? > > LLVM is not doing anything wrong here. The issue is that once we have UB, > LLVM is not required to lay out the functions nicely. For example, issue > #53118 is just a "nice to fix", it's not a bug. > On the other hand, I understand that fixing `objtool` is likely impossible if > we consider this UB thing as assembly doesn't have enough information to > distinguish between a compiler bug and a UB case. I just don't know how > frequent and/or useful these warnings are. > > I don't think we should hold this patch anymore as it's not wrong and the > side-effects are understood. We can and should try to reduce those kernel > warnings to zero, but we cannot put all that burden on this patch's author. Fair enough. We will just try to deal with this change on the kernel side in one way or another. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D105169/new/ https://reviews.llvm.org/D105169 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
