[PATCH] Fix remaining issues in PR46221/46674 wrt. unreachable alias analysis.

[Richard Guenther]

On Thu, Dec 16, 2010 at 6:14 AM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>
>    Hi list,
>
>  The committed bugfix to PR46221 turned out to have some problems vs. symbols
> with explicit _asm("") names and targets that have non-empty
> USER_LABEL_PREFIX; these subsequent problems have been filed as PR46674.
> These knock-on problems arise when we find ourselves attempting to compare an
> alias - a C-level (by which I mean, non-user-label-prefixed) identifier -
> against a decl that has already had its assembler name set.
>
>  The attached patch resolves the problems with this alias analysis by always
> operating on the underlying assembler names, using the recently-introduced
> TARGET_MANGLE_ASSEMBLER_NAME hook to lower C-level symbol names to the
> assembler level.  This canonicalises all the names into their most definitive
> forms, guaranteeing their commensurability.  The exact form of the names we
> use in the analysis isn't relevant, just so long as they are comparable, since
> we're only doing seen/not-seen testing here.

Is it only me or why does alias_set_t make me think of alias analysis?
Please instead use symbol_alias_set_*.

+static alias_set_t
+*alias_set_create (void)

the * goes on the previous line.  All functions need the usual
toplevel comments.

Ok with those changes.

Thanks,
Richard.

> gcc/ChangeLog:
>
> 2010-12-16  Dave Korn  <...
>
>        PR middle-end/46674
>        PR middle-end/46221
>        * varasm.c (alias_set_t): New typedef for pointer_set wrapper class.
>        (alias_set_create): New wrapper function.
>        (alias_set_destroy): Likewise.
>        (alias_set_contains): Likewise.
>        (alias_set_insert): Likewise.
>        (compute_visible_aliases): Use the above and return an alias_set,
>        not a pointer_set.
>        (remove_unreachable_alias_pairs): Adjust likewise to match.
>        (finish_aliases_1): Likewise.
>
>
>  LTO-bootstrapped on x86_64-unknown-linux-gnu in all of
> c,c++,objc,obj-c++,fortran,java and tested without regressions.  Bootstrapped
> on i686-pc-cygwin, tests still running, but first verified manually that the
>
>> FAIL: gcc.dg/pr46674.c scan-assembler wobbly
>
> excess error was gone.  OK for trunk once the cygwin tests have run without
> regresions?
>
>    cheers,
>      DaveK
>
>
>