[Bug c++/57378] New: gnu multiversioning gives assembler error: foo.resolver is already defined

[Bug c++/57378] New: gnu multiversioning gives assembler error: foo.resolver is already defined

[mib.bugzilla at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57378

            Bug ID: 57378
           Summary: gnu multiversioning gives assembler error:
                    foo.resolver is already defined
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mib.bugzilla at gmail dot com

% /rdrive/ref/gcc/bin/g++48 -c foo.cpp
/tmp/cc9uFaZR.s: Assembler messages:
/tmp/cc9uFaZR.s:116: Error: symbol `_Z3foov.resolver' is already defined
% cat foo.cpp
int foo () __attribute__ ((target ("default")));
int foo () __attribute__ ((target ("arch=core2")));

static int fumm();

#include <stdio.h>
int main ()
{
  int f = foo();
  printf("foo is %d\n", f);
  printf("fumm is %d\n", fumm());
  return 0;
}

__attribute__ ((target ("default")))
int foo () { return 0; }

__attribute__ ((target ("arch=corei7")))
int foo () { return 7; }

static int fumm()
{ return foo(); } 

% /rdrive/ref/gcc/bin/g++48 -v
Using built-in specs.
COLLECT_GCC=/rdrive/ref/gcc/4.8.0/rhel60/efi2/bin/g++
COLLECT_LTO_WRAPPER=/site/spt/rdrive/ref/gcc/4.8.0/rhel60/efi2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.0/gcc-4.8.0/configure
--prefix=/rdrive/ref/gcc/4.8.0/rhel60/efi2
--enable-languages=c,c++,objc,fortran --disable-multilib --enable-bootstrap
--target=x86_64-unknown-linux-gnu --disable-bootstrap --enable-decimal-float
--with-gmp=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2
--with-mpfr=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2
--with-mpc=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2
Thread model: posix
gcc version 4.8.0 (GCC)

Platform is corei7 (sandybridge)

[Bug c++/57378] gnu multiversioning gives assembler error: foo.resolver is already defined

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57378

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-05-23
                 CC|                            |tmsriram at google dot com
            Version|unknown                     |4.8.0
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug c++/57378] gnu multiversioning gives assembler error: foo.resolver is already defined

[tmsriram at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57378

Sriraman Tallam <tmsriram at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davidxl at google dot com

--- Comment #2 from Sriraman Tallam <tmsriram at google dot com> ---
First, what is happening here is the first call to foo is only seeing 2
versions and the second call to foo is seeing the 3rd corei7 version. Was this
intentional?  

When the dispatcher/resovler decl is created, the cgraph nodes of all versions
are mapped to this decl. However, the new version decl (corei7 version) is
created later, after the first call, and hence it is not mapped to the
dispatcher function decl that was previously generated. Hence the second call
re-generates it.

There are a couple of issues here. Should the first call to foo () even get
access to the corei7 version which is not visible? If the corei7 version should
not be visible to the first call I must create 2 resolvers, one for the first
call and the other for the second call.  This gets complicated and I want to
leave this for future enhancement.

Currently, what is supported is that all calls must see all the versions that
will be created. I can create a patch to generate an appropriate error here  so
that this is made clear.

[Bug c++/57378] gnu multiversioning gives assembler error: foo.resolver is already defined

[davidxl at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57378

--- Comment #3 from davidxl at google dot com ---

Can the resolver node be updated? or a new dispatcher/resolver is created?

The user code looks fine to me, which exposes the implementation limitation.

David

(In reply to Sriraman Tallam from comment #2)
> First, what is happening here is the first call to foo is only seeing 2
> versions and the second call to foo is seeing the 3rd corei7 version. Was
> this intentional?  
> 
> When the dispatcher/resovler decl is created, the cgraph nodes of all
> versions are mapped to this decl. However, the new version decl (corei7
> version) is created later, after the first call, and hence it is not mapped
> to the dispatcher function decl that was previously generated. Hence the
> second call re-generates it.
> 
> There are a couple of issues here. Should the first call to foo () even get
> access to the corei7 version which is not visible? If the corei7 version
> should not be visible to the first call I must create 2 resolvers, one for
> the first call and the other for the second call.  This gets complicated and
> I want to leave this for future enhancement.
> 
> Currently, what is supported is that all calls must see all the versions
> that will be created. I can create a patch to generate an appropriate error
> here  so that this is made clear.

[Bug c++/57378] gnu multiversioning gives assembler error: foo.resolver is already defined

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note with checking enabled we get an ICE:
<source>:23:17: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
   23 | { return foo(); }
      |                 ^
_Z3foov.resolver/12 (_Z3foov.resolver)
....