jcai19 added a comment. > I'd also like to see the pragma attribute approach, as well as byte-pattern > variability as I described. I don't think auto-narrowing is the only approach > we should push people towards.
Thank you for all the feedback. I agree, the pragma attribute and the byte-pattern approach are versatile, and great to have along the proposed approach. Will work on that and iterate on this patch based on the feedback. > Do you have an existing experience of using this flag in your build? What's > your strategy for using it? Thank you for sharing your experience. It's great to know other people are facing similar challenges. I used this flag to debug an issue <https://bugs.chromium.org/p/chromium/issues/detail?id=1042443> while enabling -ftrivial-auto-var-init=pattern on ChromeOS kernel 4.14. I used a bisection tool that traced the issue into the file of interest, but I did not know which part of the code caused the issue. That file had many <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-4.14/sound/soc/soc-core.c> small functions and local variables so it would be time consuming to manually fiddle with each variable to find out the root cause. On Linux kernel, it's easy to add build flags to each individual files, and ChromeOS provided a tool to update the OS on the test device, so each time I increased the counter with the proposed option and rebuilt the kernel, I updated the test device with the new kernel to verify if the issue still reproduce. Eventually it turned out some variable was used before [initialized](crrev.com/c/2020401). It seems your scenario is slightly different, in the sense you already know which portion of the code is problematic, in that case a pragma-driven approach should work perfectly. > In our build, we always apply flags to the entire target, not individual > files, so to use the proposed flag, I'd have to modify the build to extract a > single file into a separate target in order to apply the flag only to that > file which seems comparatively intrusive to inserting the pragma. Is that > something you could comment on? I am not familiar with Fuchsia build system, it does sound more complicated if you have to create a separate build target to just pass the flag. However, you will need this flag most likely when you run into an issue and you do not have much idea what might have been the cause, so I assume this will not happen that often :). And IMO the time saved from automating the bisect process should more than enough cover the extra effort for creating the build targets in those cases. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77168/new/ https://reviews.llvm.org/D77168 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
