[Bug target/59865] gnu multiversion calculates wrong target

["egallager at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59865

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-unknown-linux-gnu
                 CC|                            |egallager at gcc dot gnu.org
          Component|c++                         |target

--- Comment #3 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to mib.bugzilla from comment #2)
> Thanks. I realized after I posted that the test case isn't definitive.
> Improved test case pasted below.
> 
> Inspection of the assembly listing shows that popcnt is being checked before
> arch=corei7.  I was testing to see the precendence of arch= versus isa by
> creating foo for all isa, then seeing where a single arch= is sorted in the
> dispatch function.
> 
> cat core-pop.C
> #include <assert.h>
> #include <string.h>
> #include <cstdio>
> const char * __attribute__ ((target("default"))) foo(void)
> { return("default wins\n");}
> const char* __attribute__ ((target("arch=corei7"))) foo(void)
> { return("corei7 wins\n");}
> const char* __attribute__ ((target("popcnt"))) foo(void)
> { return("popcnt wins\n");}
> int main ()
> {
>   const char *result = foo ();
>   if (__builtin_cpu_is ("corei7")) puts("builtin cpu is corei7\n");
>   if (__builtin_cpu_is ("corei7"))
>     assert ( 0 == strcmp(result, "corei7 wins"));
>   return 0;
> }
> -bash-4.1$ g++ core-pop.C -S
> -bash-4.1$ g++ core-pop.C
> -bash-4.1$ grep movl core-pop.s | grep foov //From dispatch function
>         movl    $_Z3foov.popcnt, %eax
>         movl    $_Z3foov.arch_corei7, %eax
>         movl    $_Z3foov, %eax
> -bash-4.1$ ./a.out
> builtin cpu is corei7
> 
> a.out: core-pop.C:15: int main(): Assertion `0 == strcmp(result, "corei7
> wins")' failed.
> Aborted (core dumped)

I can't reproduce this bug due to my target lacking ifunc support. Someone with
a more capable target will need to test to be able to move this bug out of
WAITING.