On Fri, 2 Oct 2020 at 20:23, Nathan Sidwell <nat...@acm.org> wrote: > > > For 'no such binding' errors, we iterate over binding levels to find a > close match. At the namespace level we were using DECL_ANTICIPATED to > skip undeclared builtins. But (a) there are other unnameable things > there and (b) decl-anticipated is about to go away. This changes the > namespace scanning to iterate over the hash table, and look at > non-hidden bindings. This does mean we look at fewer strings > (hurrarh), but the order we meet them is somewhat 'random'. Our > distance measure is not very fine grained, and a couple of testcases > change their suggestion. I notice for the c/c++ common one, we now > match the output of the C compiler. For the other one we think 'int' > and 'int64_t' have the same distance from 'int64', and now meet the > former first. That's a little unfortunate. If it's too problematic I > suppose we could sort the strings via an intermediate array before > measuring distance. > > gcc/cp/ > * name-lookup.c (consider_decl): New, broken out of ... > (consider_binding_level): ... here. Iterate the hash table for > namespace bindings. > gcc/testsuite/ > * c-c++-common/spellcheck-reserved.c: Adjust diagnostic. > * g++.dg/spellcheck-typenames.C: Adjust diagnostic. > > pushing to trunk >
Hi Nathan, This is causing regressions on aarch64 and arm when using -mfloat-abi=hard (or configuring for arm-linux-gnueabihf). The logs says: FAIL: c-c++-common/spellcheck-reserved.c -std=gnu++98 (test for excess errors) Excess errors: /gcc/testsuite/c-c++-common/spellcheck-reserved.c:31:3: error: '__builtin_strtchr' was not declared in this scope; did you mean '__builtin_strrchr'? The test still passes on arm with -mfloat=abi=soft Christophe > nathan > > -- > Nathan Sidwell
