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

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
Note with checking enabled we get an ICE:
: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)

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

[nheart at gmail dot com]

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

Nikolay Bogoychev  changed:

   What|Removed |Added

 CC||nheart at gmail dot com

--- Comment #4 from Nikolay Bogoychev  ---
Still an issue in 8.3.0

Works in clang

Cheers,

Nick

[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

[tmsriram at google dot com]

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

Sriraman Tallam  changed:

   What|Removed |Added

 CC||davidxl at google dot com

--- Comment #2 from Sriraman Tallam  ---
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

[rguenth at gcc dot gnu.org]

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

Richard Biener  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  ---
Confirmed.