On Dec 15, 2023, Richard Biener <rguent...@suse.de> wrote: > You have to be generally careful when working within IPA > with function bodies without push/pop_cfun around that, several APIs > have variants with struct function sepcified, using the wrong one > will get you a NULL cfun which _some_ of them handle gracefully and > "wrong", all EH stuff is amongst this for example.
*nod*, I recall running into that, and finding some APIs that required push/pop_cfun, so since I was implementing strub so that it could be plugged into an existing compiler, I didn't give much thought to introducing alternate APIs that could. IIRC I first hit something about EH, and then I had to put in push/pop_cfun. That was very early on, so after that I may have used implicit-cfun APIs without getting ICEs. I suppose now that strub is in pursuing push/pop_cfun avoidance could be a nice cleanup. > I see you replace flag_exceptions with opt_for_fn (cfun->decl, > flag_exceptions), given that's 'cfun' this replacement is a no-op > given 'cfun' would be NULL in IPA context unless you pushed a function. > Looking at the 2nd hunk and the caller it seems the transform is > a no-op for indrect_calls but not callees, thus that hunk is OK. Yeah, I figured that was the reason behind your recommendation, but I guess adding explicit uses of cfun (rather than passing a function around) doesn't really make things much better, except inasmuchas it enables a future de-cfun-ification of strub passes to be a little more mechanical. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
