public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/98485] New: Symbols for identical constrained specializations have different linkage
@ 2020-12-31  1:34 admin at maniacsvault dot net
  2020-12-31  8:46 ` [Bug c++/98485] " pinskia at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: admin at maniacsvault dot net @ 2020-12-31  1:34 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 98485
           Summary: Symbols for identical constrained specializations have
                    different linkage
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: admin at maniacsvault dot net
  Target Milestone: ---

Created attachment 49861
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49861&action=edit
Minimal example code

When using multiple constrained specializations, the symbols generated have
different linkage based on the order the specializations are defined in the
file.  The first specialization will generate weak symbols as expected, the
second generates local symbols.

See attached example. S1 is a structure containing a static member function. 
S2 and S3 differ in some way that's detectable through concepts.  main.cpp can
only see these definitions so all it knows is that S1<T>::f() is forward
declared.  a.cpp and b.cpp include s1-defs.h which contains two basically
identical specializations of S1.  The first is applied for S2, the second for
S3.  a.cpp instantiates S1<S2>.  b.cpp instantiates S1<S3>.  These do not need
to be separate files, this was just done to make it easier to diff the two
outputs.  What you will notice is that a.o contains an externally visible
S1<S2>::f1 symbol.  b.o contains a local S1<S3>::f1 symbol.  Thus the program
can't link since main can't reference S1<S3>::f1.

Despite there being basically no difference in the two specializations the
linkage is unexpectedly different.  If the order of the two specializations in
s1-defs.h is reversed then S1<S2>::f1 will become problematic.

In s1-defs.h there's a USE_SINGLE define which when toggled uses if constexpr
instead of two specializations.  This effectively works around the issue and
the program links.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c++/98485] Symbols for identical constrained specializations have different linkage
  2020-12-31  1:34 [Bug c++/98485] New: Symbols for identical constrained specializations have different linkage admin at maniacsvault dot net
@ 2020-12-31  8:46 ` pinskia at gcc dot gnu.org
  2020-12-31 10:15 ` admin at maniacsvault dot net
  2020-12-31 11:01 ` admin at maniacsvault dot net
  2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-12-31  8:46 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I thought the C++ rule was all specializations has to be seen when you use one
or the other.  Otherwise this becomes an ODR issue and therefor invalid code
(not have to be diagnostic at compile time).

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c++/98485] Symbols for identical constrained specializations have different linkage
  2020-12-31  1:34 [Bug c++/98485] New: Symbols for identical constrained specializations have different linkage admin at maniacsvault dot net
  2020-12-31  8:46 ` [Bug c++/98485] " pinskia at gcc dot gnu.org
@ 2020-12-31 10:15 ` admin at maniacsvault dot net
  2020-12-31 11:01 ` admin at maniacsvault dot net
  2 siblings, 0 replies; 4+ messages in thread
From: admin at maniacsvault dot net @ 2020-12-31 10:15 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Braden Obrzut <admin at maniacsvault dot net> ---
I'm actually not certain if I'm playing fast and loose with ODR.  While I can
definitely agree that this construct is fragile, if a specialization has the
same sequence of tokens as the base template is it actually considered a
different definition?  Thinking of C++20 6.3 paragraph 13.8 here.

While same sequence of tokens isn't strictly true in the provided example, one
could easily hoist the definitions of f1 out of the structure definition to
make each specialization exactly the same as the base template and GCC still
wants to use internal linkage for the second specialization.

Not that it technically would matter if it's indeed an ODR violation, but Clang
does seem to work as expected for this scenario.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c++/98485] Symbols for identical constrained specializations have different linkage
  2020-12-31  1:34 [Bug c++/98485] New: Symbols for identical constrained specializations have different linkage admin at maniacsvault dot net
  2020-12-31  8:46 ` [Bug c++/98485] " pinskia at gcc dot gnu.org
  2020-12-31 10:15 ` admin at maniacsvault dot net
@ 2020-12-31 11:01 ` admin at maniacsvault dot net
  2 siblings, 0 replies; 4+ messages in thread
From: admin at maniacsvault dot net @ 2020-12-31 11:01 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Braden Obrzut <admin at maniacsvault dot net> ---
Created attachment 49864
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49864&action=edit
More well defined variant

Added a variant of the code which has all specializations visible at all uses. 
Only thing hidden is the S1<T>::f1 definition itself which should be valid to
do given explicit instantiations.

Same behavior of the second specialization having different linkage for some
reason.  Although in this case a compiler warning is produced on main.cpp.

main.h:25:28: warning: ‘static void S1<T>::f1() [with T = S3]’ used but never
defined

Interestingly despite presumably being more well defined Clang 11 doesn't like
this version at all.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-12-31 11:01 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-31  1:34 [Bug c++/98485] New: Symbols for identical constrained specializations have different linkage admin at maniacsvault dot net
2020-12-31  8:46 ` [Bug c++/98485] " pinskia at gcc dot gnu.org
2020-12-31 10:15 ` admin at maniacsvault dot net
2020-12-31 11:01 ` admin at maniacsvault dot net

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).