On Thu, 2020-01-23 at 17:16 -0500, David Malcolm wrote: > On Wed, 2020-01-22 at 20:40 +0100, Jakub Jelinek wrote: > > On Wed, Jan 22, 2020 at 02:35:13PM -0500, David Malcolm wrote: > > > PR analyzer/93316 reports various testsuite failures where I > > > accidentally relied on properties of x86_64-pc-linux-gnu. > > > > > > The following patch fixes them on sparc-sun-solaris2.11 (gcc211 > > > in > > > the > > > GCC compile farm), and, I hope, the other configurations showing > > > failures. > > > > > > There may still be other failures for pattern-test-2.c, which I'm > > > tracking separately as PR analyzer/93291. > > > > > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu; > > > tested on stage 1 on sparc-sun-solaris2.11. > > > > > > gcc/analyzer/ChangeLog: > > > PR analyzer/93316 > > > * analyzer.cc (is_setjmp_call_p): Check for "setjmp" as well as > > > "_setjmp". > > > > Please see calls.c (special_function_p), you should treat certainly > > also sigsetjmp as a setjmp call, and similarly to > > special_function_p, > > skip over _ or __ prefixes before the setjmp or sigsetjmp name. > > Similarly for longjmp/siglongjmp. > > > > Jakub > > Thanks. > > This patch removes the hack in is_setjmp_call_p of looking for > "setjmp" and "_setjmp", replacing it with some logic adapted from > special_function_p in calls.c, ignoring up to 2 leading underscores > from > the fndecl's name when checking for a function by name. > > It also requires that such functions are "extern" and at file scope > for them to be matched. > > The patch also generalizes the setjmp/longjmp handling in the > analyzer > to also work with sigsetjmp/siglongjmp. Doing so requires > generalizing > some hardcoded functions in diagnostics (which were hardcoded to > avoid > user-facing messages referring to "_setjmp", which is an > implementation > detail) - the patch adds a new function, get_user_facing_name for > this, > for use on calls that matched is_named_call_p and > is_specical_named_call_p. > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > OK for master?
I've gone ahead and committed this, based on Jeff's blanket approval here: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01689.html I'm working on a followup which would refactor it to share more code with calls.c (which would need review, as it would touch calls.c). Dave
