On Tue, Oct 10, 2017 at 3:03 PM, Nathan Sidwell <nat...@acm.org> wrote: > I have a patch cleaning up a bit of the C++ FE, which will involve hashing > via DECL_ASSEMBLER_NAME. however, all the items in that hash are known to > have it set, so its mapping to a function call is undesirable. > > This patch adds DECL_ASSEMBLER_NAME_RAW, which gets at the field directly. > I can then use that for my hash table. The cleanup to use that is fairly > trivial. > > However, I also looked more deeply at DECL_ASSEMBLER_NAME_SET_P. It does > more than the name suggests -- namely checking HAS_DECL_ASSEMBLER_NAME_P > too. There are about 72 uses of DECL_ASSEMBLER_NAME_SET_P and investigation > showed only about 4 applying it to decls that are not > HAS_DECL_ASSEMBLER_NAME_P. So, I remove the HAS_DECL_ASSEMBLER_NAME_P from > DECL_ASSEMBLER_NAME_SET_P and explicitly check it at the 4 locations that > need it. > > In doing this I noticed a couple of items: > > 1) ipa-utils.h (type_in_anonymous_namespace_p) is applying > HAS_DECL_ASSEMBLER_NAME_P to a type. That's clearly wrong, It looks like a > thinko for TYPE_NAME (t). Making that change seems fine. > > 2) tree-ssa-structalias.c (alias_get_name) seemed overly complicated, so I > reimplemented it. > > I checked the target-specific code, and there are only two uses of > DECL_ASSEMBLER_NAME_SET_P. Both look safe to me (the avr one seems > superfluous, and DECL_ASSEMBLER_NAME would be fine there. > > booted on x86_64-linux > > ok?
Ok. Thanks, Richard. > nathan > -- > Nathan Sidwell
